FWIW, when I checked, ByteBuffer.wrap(...).getXXX() type of code didn't EA
out the BB; it seems the call chain is too complex for EA. I checked 7u60
though, so maybe newer versions are different.
sent from my phone
On Feb 17, 2015 5:53 AM, "Andrew Haley" <a...@redhat.com> wrote:
> 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.
>
>
>
