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

[David Chase]

On 2013-05-16, at 11:06 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 17/05/2013 12:26 PM, David Chase wrote:
>> 
>> 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?

No, since I am loading-casting-storing values.
And I'm developing on a Mac, which is how I spotted the issue.
And I've also tested on both Sparc and Intel, so both endianness, just because it never hurts to check.

The accelerated CRC code is fantastically sensitive to endianness, but it only runs on one architecture, so that is okay.

David