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