It is extremely common in performance sensitive code, 1) graphics & rendering 2) networking 3) buffers
> But further newer JVM additions like the enhanced for loop eliminate a ton of conditions > The JVM is far more likely today to remove the bounds check all together than it ever was in 2004.
There are more comments in this thread that clarify further, but Java is very commonly unable to eliminate bounds checks. You can test all of these things yourself with a quick benchmark - don't take my word for it! The JIT is not as great at this as common rhetoric claims it is.
HotSpot had been part of the JVM for five years at that point.
That said, in the paper they didn't use sun's JVM they used gcj and their own modified version of gcj.
> We examined the performance of both our new Java implementation as well as standard gcj on a variety of Java applications.
So my point still stands, a lot as changed. The researches chose to use static compilation over a JIT or interpreter.
It's a writing error on my end (clear since I qualify the percentage afterwards), so I think focusing on it distracts from the point (which is why I say it's pedantic).
I understand the pet peeve though (-:
Also accessing byte arrays and direct buffers is extremely common - if you do just "business logic" jazz - it does not happen, though. However, every hashmap needs that, pretty much each hash lookup is a direct a[hash]
Um... yeah it has. For starters, hotspot wasn't even a part of the JVM at that point. But further newer JVM additions like the enhanced for loop eliminate a ton of conditions where someone would run into bounds checking. Doing a naked `a[i]` is simply not common java code.
The JVM is far more likely today to remove the bounds check all together than it ever was in 2004.