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

David Chase david.r.chase at oracle.com
Thu May 23 16:06:27 UTC 2013

So where do we stand on this? Can we call it a bug and eligible for inclusion? And are there other issues to deal with?

I would be happy to discuss exactly what is going on in the mysterious intrinsic-ful code, if that is an issue for anyone (and sooner is better than later, else I'll forget the exciting details).

David

On 2013-05-21, at 5:15 PM, David Chase <david.r.chase at oracle.com> wrote:

http://cr.openjdk.java.net/~drchase/7088419/webrev.03/ Newer, slimmer webrev. No fork/join, the related code is removed (except the native init routine still returns a boolean, which is currently ignored, indicating if it supports the faster crc32). What remains is: 1) no-JNI fast-path for short CRCs and Adlers 2) reformulated faster-Adler for byte-at-a-time 3) For 32/64 Linux/Solaris/MacOS x86 Sandy Bridge or better (with CLMUL and AVX), fast code for CRCs. For now it uses assembly language, the C-with-intrinsics is included, and compiles with current clang and gcc. It tickles a bug in Solaris Studio 12.3 which has been reported. Optimization for Windows is disabled because the assembler syntax is too different The code has been tested by-hand across Linux (32), Solaris (32 and 64), MacOS (64) and has also passed JPRT (which is to say, the failures were unrelated, hand examination of the runs showed that the new CRCandAdler test was successful. Anyone checking my most recent run will notice that I am not very good at specifying tests to run, but there is an earlier run. I'm trying again, just to see if I can figure out how to make it behave.) There is a companion webrev on the hotspot side that sets the secret property that is used and reset by this code. I hope this will be more easily regarded as a "bug fix" and less as an interface change. David On 2013-05-20, at 8:34 PM, David Holmes <david.holmes at oracle.com> wrote:

On 21/05/2013 3:45 AM, Alan Bateman wrote: On 20/05/2013 14:49, David Chase wrote:

Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. :

This make sense. I agree. I also don't have an issue with eliding the optimization on Windows for the time being. David -Alan.

More information about the core-libs-dev mailing list