RFR (M): 8143925: Enhancing CounterMode.crypt() for AES
vladimir.kozlov at oracle.com
Wed Jan 6 22:25:40 UTC 2016
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.
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.
> -----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.
> 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
>> (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?
More information about the hotspot-compiler-dev