RFR JDK-6321472: Add CRC-32C API
peter.levart at gmail.com
Fri Oct 17 08:46:16 UTC 2014
On 10/17/2014 03:42 AM, Staffan Friberg wrote:
> This RFE adds a CRC-32C class. It implements Checksum so it will have
> the same API CRC-32, but use a different polynomial when calculating
> the CRC checksum.
> CRC-32C implementation uses slicing-by-8 to achieve high performance
> when calculating the CRC value.
> A part from adding the new class, java.util.zip.CRC32C, I have also
> added two default methods to Checksum. These are methods that were
> added to Adler32 and CRC32 in JDK 8 but before default methods were
> added, which was why they were only added to the implementors and not
> the interface.
> Bug: https://bugs.openjdk.java.net/browse/JDK-6321472
> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.00
> I have started a CCC request for the changes, but was asked to get
> feedback from the core libs group before finalizing the request in
> case there are any API or Javadoc changes suggested.
I can see CRC32C.reflect(int) method reverses the bits in 32 bit int
value. You could use Integer.reverse(int) instead.
The CRC32C.swap32(int) method is (almost) exactly the same as
Integer.reverseBytes(int) and equivalent.
I wonder if handling ByteBuffer could be simplified. You could leverage
it's own byte order manipulation by temporarily setting (and resetting
afterwards) ByteBuffer.order() and then use ByteBuffer.getInt() to
extract 32 bits at a time for your algorithm. This could get you the
optimal variant of algorithm for both kinds of buffers (direct or byte
based). Perhaps even the byte based variant of algorithm could be
implemented by wrapping the array with ByteBuffer, passing it to common
private method, and relying on the escape analysis of Hotspot to
allocate the HeapByteBuffer wrapper object on stack.
More information about the core-libs-dev