RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
Andrew Haley
aph at redhat.com
Tue Feb 17 10:53:20 UTC 2015
On 02/17/2015 10:49 AM, Florian Weimer wrote:
> On 02/17/2015 11:22 AM, Andrew Haley wrote:
>>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>>> I expect that makes them unattractive in many cases.
>>
>> Hmm. I'm having a hard time trying to understand why. If you need to
>> do a lot of accesses the allocation of the ByteBuffer won't be
>> significant; if you don't need to do a lot of accesses it won't
>> matter either.
>
> The typical use case I have in mind is exemplified by
> com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs):
>
> 174 private void processBlock(byte[] data, int ofs) {
> 175 if (data.length - ofs < AES_BLOCK_SIZE) {
> 176 throw new RuntimeException("need complete block");
> 177 }
> 178 state0 ^= getLong(data, ofs);
> 179 state1 ^= getLong(data, ofs + 8);
> 180 blockMult(subkeyH0, subkeyH1);
> 181 }
>
> That is, the byte array is supplied by the caller, and if we wanted to
> use a ByteBuffer, we would have to allocate a fresh one on every
> iteration. In this case, neither of the two alternatives you list apply.
I see. So the question could also be whether escape analysis would
notice that a ByteBuffer does not escape. I hope to know that soon.
Andrew.
More information about the core-libs-dev
mailing list