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

[Alan Bateman]

On 16/05/2013 15:50, David Chase wrote:
> webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
>
> problem: Some applications spend a surprising amount of time computing CRC32s
> (Not sure I'm supposed to be precise on an open mailing list).  Recent Intel
> architectures provide instructions that might be useful in addressing this.
>
> See https://jbs.oracle.com/bugs/browse/JDK-7088419
>
> I turned this into a general attack on performance in Adler32 and CRC32, partly because the bug report was not clear on the size of the problematic inputs.  The general approach turned out to be useful, because it's tricky to get the small-case overheads down for the accelerated-instruction version of the code.
>
I took a second pass over the webrev. If we've going to have assembly in 
CRC32.c then it makes me wonder if this should be the place to probe if 
CLMUL is supported. Clearly there may be others cases where the VM needs 
to probe too but I'm just wondering if the capability really needs to be 
communicated via a property (at least for now). The other thing that 
comes to mind is whether we could re-write it in java in a way that 
allows C2 to generate code that uses CLMUL. I realize that is probably a 
much bigger effort but I can imagine other cases (like crypto where it 
could be useful too).

On using Unsafe to get the alignment then you can use Unsafe.getUnsafe() 
rather than reflection.

On my comment about whether a parallelUpdate method has been considered 
then my personal view this would make it obvious when looking at the 
code. That is, have the long standing update methods be serial by 
default and introduce new parallelUpdate methods. For existing code then 
you could have the system property to opt-in to be parallel when the 
input length is over the threshold (and that should okay to backport to 
jdk7u if needed).

-Alan.