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

[Kharbas, Kishor]

Thank you guys for the in detail discussion and review.

I have patched the JDK, performing bound checking using Objects.checkFromIndexSize() in CounterMode.crypt() and AESCrypt.encryptBlock(), AESCrypt.decryptBlock()
Here is the link - http://cr.openjdk.java.net/~vdeshpande/8135250/webrev.00/

Let me know if it looks correct.

-Kishor

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Tuesday, January 05, 2016 9:17 AM
To: Andrew Haley; John Rose
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8143925: Enhancing CounterMode.crypt() for AES

 > 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.
>