RFR JDK-6321472: Add CRC-32C API

Peter Levart peter.levart at gmail.com
Fri Oct 17 18:36:54 UTC 2014


Hi Staffan,

You're right. I thought ByteBuffer was more optimal in this respect.

Regards, Peter

On 10/17/2014 06:47 PM, Staffan Friberg wrote:
> Hi Peter,
>
> Thanks for reviewing.
>
> I have switched to the Integer methods. Was looking through that API 
> but I was too stuck with the reflect and swap names so I missed the 
> reverse methods... :)
>
> As Vitaly noted in his email the wrapped case runs much slower. Going 
> through the generated code it looks like the getInt method actually 
> read four bytes and then builds and int from them, unless we have some 
> intrinsic replacing that code.
>
> Bits.java
>     static int getIntL(long a) {
>         return makeInt(_get(a + 3),
>                        _get(a + 2),
>                        _get(a + 1),
>                        _get(a    ));
>     }
>
>     static private int makeInt(byte b3, byte b2, byte b1, byte b0) {
>         return (((b3       ) << 24) |
>                 ((b2 & 0xff) << 16) |
>                 ((b1 & 0xff) <<  8) |
>                 ((b0 & 0xff)      ));
>     }
>
> It looks like the same holds true for DirectByteBuffers unless you are 
> on x86 which supports unaligned reads. So I think aligning and using 
> Unsafe is the best option here for performance.
>
> DirectByteBuffer.java
>     private int getInt(long a) {
>         if (unaligned) {
>             int x = unsafe.getInt(a);
>             return (nativeByteOrder ? x : Bits.swap(x));
>         }
>         return Bits.getInt(a, bigEndian);
>     }
>
> Bits.java
>     static boolean unaligned() {
>         if (unalignedKnown)
>             return unaligned;
>         String arch = AccessController.doPrivileged(
>             new sun.security.action.GetPropertyAction("os.arch"));
>         unaligned = arch.equals("i386") || arch.equals("x86")
>             || arch.equals("amd64") || arch.equals("x86_64");
>         unalignedKnown = true;
>         return unaligned;
>     }
>
> Regards,
> Staffan




More information about the core-libs-dev mailing list