RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

[David Holmes]

On 17/05/2013 12:26 PM, David Chase wrote:
>
> On 2013-05-16, at 10:15 PM, David Holmes <david.holmes at oracle.com> wrote:
>> BTW while at this code I don't understand the issue with size of long and copying "one at a time". Where are the "unsigned longs"? and should we be using them if we don't even know they will be larger than unsigned ints?
>
>
> The values are well known and invariant -- they depend on the CRC32 properties -- and only contain 32 bits of interesting data each.  We need to make a copy of them for the Java code (to enable both the small-array fast path, and the combine operation for fork/join).  I think that doing this copy in C code from an existing copy into an array of java int (known 32 bytes) is the fastest and smallest footprint way to do it (vs. interpreting Java array initialization) and we are doing the JNI handshake anyway to be sure that both sides agree on the existence or not of CLMUL acceleration.
>
> They're stored in "unsigned long" (that is how zlib declares them) and at least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good idea.  When the fast-path algorithm is enabled, this is also the last time that the old crc32 table is referenced (it contains 1024 entries, so it is 8k, versus 1K for this) so we can even claim some small reduction in effective footprint.

Mac is 64-bit. All our supported platforms either use the ILP32 data 
model, else the LP64 data model.

So on 64-bit does this copying potentially have endian issues?

David H.

> David
>