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

[David Chase]

On 2013-05-20, at 3:33 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> I think we need to get more experience with parallel operations before considering changing the default behavior of long standing methods. This it why I am suggesting this should be opt-in, meaning you run with something like -Djdk.enableParallelCRC32Update=true to have the existing methods use FJ. Having it opt-in rather than opt-out would also reduce concerns if this is proposed to be back-ported to jdk7u. I don't have an opinion as to whether other tuning knobs are required.

If that's what it takes to get this in, then I suppose  -Djdk.enableParallelCRC32Update=true  is the way to go.
What steps do we/I take to get a public flag like that added?

And would you consider instead -Djava.util.zip.CRC32.serialSize=4g, meaning for all inputs smaller than 4g (unsigned, thus larger than any Java array this year), do it in serial?  Because there are quite a few boxes that I benchmarked on where you might want to tune that threshold down below 4m (the default that I had proposed).

> At this point, we have Arrays.parallelSort and the Streams API defines the parallel() method to get a stream that is parallel. Having the word "parallel" in the code means it is clear and obvious when reading the code (no surprises). Maybe going forward that this will be unnecessary, meaning it will be transparent. For now though, I think we should at least consider adding parallelUpdate methods.

I think in a few years we will view this as an anachronism, which is why, if we do it with a flag, we make it a tuning flag that people are likely to want anyhow and just leave the default threshold at "really big" if we are worried about behavioral changes in the near term.  This is our future; we're unlikely to see clock speeds 3.6x what we have now, but can we add cores and easily get 3.6x performance boosts on stuff like CRC.  

David