Optimizing byte reverse code for int value

[Hiroshi H Horii]

> > I guess that application does not use ByteBuffer only for calling 
getInt().
> > 
> > Heap-X-Buffer.java.template
> >     public int getInt() {
> >         return Bits.getInt(this, ix(nextGetIndex(4)), bigEndian);
> >     }
> 
> This is old code.  In JDK9 it looks like
> 
>     public int getInt() {
>         return unsafe.getIntUnaligned(hb, 
> byteOffset(nextGetIndex(4)), bigEndian);
>     }
> 
> Unsafe.getIntUnaligned is a HotSpot intrinsic.

Sorry. You are right. I checked jdk8u...

jdk8u doesn't have Unsafe.getIntUnaligned. This change will improve jdk8u.

Regards,
Hiroshi

Andrew Haley <aph at redhat.com> wrote on 2017/04/08 02:58:45:

> From: Andrew Haley <aph at redhat.com>
> To: Hiroshi H Horii/Japan/IBM at IBMJP
> Cc: hotspot-dev at openjdk.java.net, Michihiro Horie/Japan/IBM at IBMJP, 
> ppc-aix-port-dev at openjdk.java.net, volker.simonis at sap.com
> Date: 2017/04/08 02:59
> Subject: Re: Optimizing byte reverse code for int value
> 
> On 07/04/17 18:51, Hiroshi H Horii wrote:
> >> I suggest replacing the use of loadI by endianness specific code
> >> (which could possibly use lwbrx on big endian).
> > 
> > I believe that lwbrx is necessary for BE.
> > 
> >> Surely the source code needs fixing.  It could be:
> >>
> >> public float readFloat(InputStream in) throws IOException {
> >>   readFully(in, aByteBuffer, 0, 4);
> >>   int val = aByteBuffer.getInt(0);
> >>
> >>   return Float.intBitsToFloat(val);
> >> }
> > 
> > In my understanding, ByteBuffer.getInt() does the similar thing.
> 
> It doesn't.
> 
> > I guess that application does not use ByteBuffer only for calling 
getInt().
> > 
> > Heap-X-Buffer.java.template
> >     public int getInt() {
> >         return Bits.getInt(this, ix(nextGetIndex(4)), bigEndian);
> >     }
> 
> This is old code.  In JDK9 it looks like
> 
>     public int getInt() {
>         return unsafe.getIntUnaligned(hb, 
> byteOffset(nextGetIndex(4)), bigEndian);
>     }
> 
> Unsafe.getIntUnaligned is a HotSpot intrinsic.
> 
> Bits.java is not used for this.
> 
> Andrew.
>