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

[Paul Sandoz]

> On 5 Jan 2016, at 10:48, Andrew Haley <aph at redhat.com> 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?
> 

My understanding is that the pattern matching can sometimes be fragile, hence a "belts and braces” approach.

It was motivated by the VarHandle work where it was observed that explicit bounds checks plus Unsafe array access produced more generated bounds checks [*] than direct array access (which does what you propose). The VarHandle array access implementations call this method before Unsafe access.

If the pattern matching gets (or is now) sufficiently reliable we could remove the intrinsic, but i would like to carefully verify before doing that.

Paul.

[*] Another case was identified for viewed indexed ByteBuffer access, where use of the Objects.checkIndex method in the following method on Buffer also reduced generated checks:

final int checkIndex(int i, int nb) {               // package-private
    if ((i < 0) || (nb > limit - i))
        throw new IndexOutOfBoundsException();
    return i;
}

(Note that this code assumes that limit is always non-negative.) I need to go back and revisit from last time i checked in September.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160105/5a397895/signature.asc>