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

[Vladimir Kozlov]

On 5/23/13 9:06 AM, David Chase wrote:
> 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).

I spent some time yesterday reading through your CRC code to understand 
what we need to do to intrinsify it. I will continue work on it today. 
We would need to move whole fastcrc32 into VM together with K_struct and 
crc_table table (first 256 entries). We can not intrinsify part of 
native (C) code.

Vladimir

>
> 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.
>>
>