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

Alan Bateman Alan.Bateman at oracle.com
Sun May 19 16:50:28 UTC 2013

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.

More information about the core-libs-dev mailing list