RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32
david.r.chase at oracle.com
Thu May 23 09:06:27 PDT 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).
On 2013-05-21, at 5:15 PM, David Chase <david.r.chase at oracle.com> wrote:
> 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.
> 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.
More information about the hotspot-compiler-dev