RFR (M): 8143925: Enhancing CounterMode.crypt() for AES

[Vladimir Kozlov]

 > On 31 Dec 2015, at 22:33, John Rose <john.r.rose at oracle.com> wrote:
 >
 > When performing explicit range checks in pre-intrinsic code,
 > let's try to use the new intrinsic functions in java.util.Objects,
 > called checkIndex, checkFromToIndex, and checkFromIndexSize.

Please, don't forget that checks in pre-intrinsic code should match checks generated by javac (bytecode) for 
intrinsified methods. Otherwise those checks will not be removed (by dominated checks in pre-intrinsic code) when 
intrinsics are not support on a platform. That is why we currently have such duplicated pre-intrinsic code.

On other hand when intrinsics are supported they don't have checks so if they present we can intrinsify pre-intrinsic 
code as you suggested.

Thanks,
Vladimir

On 1/5/16 1:48 AM, Andrew Haley wrote:
> On 04/01/16 20:12, John Rose wrote:
>> Corrected, thanks.  They don't need to be intrinsics if they optimize well.
>> The point is that the library functions have code shapes which work well
>> with the JIT.  For example, the multi-index checks might (as in Kishor's code)
>> be implemented on top of the single-index check, without themselves being
>> intrinsics.
>
> We seem to be missing the opportunity to convert
>
>    i >= 0 && i < size
>
> into
>
>    (unsigned)i < (unsigned)size
>
> and this is, as far as I can see, the only real code-quality advantage of
> the checkIndex intrinsic.  Could we not do this optimization and then
> drop the C2 checkIndex intrinsic?
>
> Andrew.
>