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

[Vladimir Kozlov]

Hi Kishor,

Please send this as separate RFR for 8135250.
RFR should be sent to jdk9-dev at openjdk.java.net since it is JDK changes.
And CC to paul.sandoz at oracle.com who is assigned to the bug.

Thanks,
Vladimir

On 1/5/16 1:39 PM, Kharbas, Kishor wrote:
> 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.
>>