Bounds checks with unsafe array access

[Paul Sandoz]

On Sep 12, 2014, at 7:59 PM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>>> Actually, we now have Integer.compareUnsigned!  
>> 
>> Ah! now it becomes obvious :-)
>> 
>>         if (Integer.compareUnsigned(index, a.length) >= 0)
>>             throw new ArrayIndexOutOfBoundsException();
>> 
>> That it should in principle, vis some intrinsification, reduce to something like a cmp/jae or test/jbe depending on what comes before it.
> 
> Yes.  I don't even think it needs intrinsifying, since its expression is simple enough to recognize in CmpINode::Ideal.

Ok, so basically detecting that Integer.MIN_VALUE is added to the two values just before the signed comparison.


>> 
>>> If we agree that is an intrinsic for range checks, the JIT will have a better optimization target to aim at.   Ultimately, we need an intrinsic (perhaps more intentional than Integer.compareUnsigned) that will encourage the JIT to treat it like a range check, doing iteration range splitting, predication, and all the rest.
>>> 
>>>> (Note: in general we cannot assume that "int index = i & (a.length - 1)" always occurs before the bounds checks, otherwise i would have explicitly written "if (a.length == 0) throw ...")
>>> 
>>> Right.  You want to factor the range check into a bit of code that doesn't know how it's going to be used, but then gets the same perks as normal array code, including the a.length==0 stuff, and the loop opts I mentioned.
>>> 
>>>> Ideally similar code as shown for an aaload should be generated. Any suggestions/ideas on how to make that happen?
>>> 
>>> First, agree on a range check intrinsic.  Then, treat optimization equity failures as JIT bugs.
>> 
>> Many thanks, seems like an excellent starting point is to intrinsify Integer.compareUnsigned and see what that yields.
> 
> I think that will get you a step forward.
> 
> The next step towards bringing unsafe ops to parity with array ops is finding out why the logic
> for -XX:+RangeCheckElimination doesn't kick in (if that indeed is the case).

AFAICT, for the basic for loop over an array, the elimination kicks in for the unrolled bits, but the pre/post bits still perform redundant checks.


> That would start with an examination of IdealLoopTree::policy_range_check.
> 

Many thanks for the pointers, I definitely have some homework to do (post J1... ),
Paul.

-------------- 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: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140917/0fa9dd3f/signature.asc>