Bounds checks with unsafe array access

Paul Sandoz paul.sandoz at
Fri Sep 12 12:40:36 UTC 2014

On Sep 11, 2014, at 10:51 PM, John Rose <john.r.rose at> wrote:
> In some cases of highly tuned code the author can work with the JIT engineer to insert the right code shapes from the start.
> The "test length against zero" code shape is one of these, and can often be merged with a check that is required any way (e.g., is the data structure logically empty?).
> For example:

A great example, i was just recently looking at that :-)

My understanding is that check ("(n = tab.length) > 0") is in place solely to generate more efficient bounds checks, since it should always return true (table is either null or non-null with a length > 0). If/when JDK-8003585 gets fixed we might be able to update the code and remove that check (or turn it into an assert if it did not interfere with inlining...).

I was naively pondering whether that table field:

could be annotated with something like @ArrayHasElementsIfNonNull, so that a write to that field would be guarded by a check which would throw an assertion error if the field would otherwise be set to an empty array.

Final field optimizations would be a bigger bang for the buck though. 

Combine that with specialization and perhaps there is an alternative implementation approach to the current VarHandles prototype?

class FieldHandle<R, any V> {
   /* really */ final Class<?> rType;
   /* really */ final Class<?> vType;
   /* really */ final long foffset;

   <where reference V>
   V getVolatile(R r) {
       rType.cast(r); // Should go away (well almost!) if FieldHandle instance is constant
       return vType.cast(U.getObjectVolatile(r, foffset));

   <where V = int>
   int getVolatile(R r) {
       return U.getIntVolatile(r, foffset);

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <>

More information about the hotspot-compiler-dev mailing list