Unsafe for array access

[John Rose]

On May 7, 2014, at 10:23 AM, David Chase <david.r.chase at oracle.com> wrote:

> Don't we now have an Unsigned class providing these operations? (which could be intrinsified)
> Or did we want to tie the intrinsic more closely to array classes?

It's not a class.  (Some day a value type!)  We have the method Integer.compareUnsigned, which should not even need intrinsifying, but may need a little pattern matching help in GVN.

Doug is suggesting (and I concur) that it would be good to package up both the test and the error path, or at least have a test method that the optimizer can treat as a never failing test.

In whatever form, the test should play nicely with range check elimination, and (probably) also with any optimistic range check related conditions, such as are found in deoptimization.hpp.

— John

> David
> 
> On 2014-05-07, at 11:56 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
>>> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>>> 
>>> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
>>> that could be used in such cases that implemented using the more efficient
>>> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
>>> efficient VM throw mechanics on failure.
>> 
>> We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application. 
>> 
>> Counterpoint:  optimizer can and should generate similar code for plain user written range tests. 
>> 
>> Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations. 
>> 
>> – John
>