RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32
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).
More information about the core-libs-dev