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