On 17/05/2013 12:26 PM, David Chase wrote:
On 2013-05-16, at 10:15 PM, David Holmes <david.hol...@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
