Use OpenJDK CRC32C while available

[franz1981]

Snappy protocol seems to leverage to our Netty CRC32C using a big lookup table and no CPU-specific intrinsics to perform xoring etc etc; OpenJDK seems to have what we need, see https://github.com/openjdk/jdk/blob/52d497619e58a5677bc4a015b1bd87f600f23837/src/java.base/share/classes/java/util/zip/CRC32C.java#L218

It would be nice to:

1. Use https://openjdk.org/jeps/416 in order to use static final reflection to call into C2C32C byte[] batch intrinsified method at https://github.com/openjdk/jdk/blob/52d497619e58a5677bc4a015b1bd87f600f23837/src/java.base/share/classes/java/util/zip/CRC32C.java#L218
2. If not possible, verify if the table generation approach at https://github.com/openjdk/jdk/blob/52d497619e58a5677bc4a015b1bd87f600f23837/src/java.base/share/classes/java/util/zip/CRC32C.java#L74 is it worthy
3. for both: run/build a crc32c & snappy-specific JMH benchmark to verify if is it worthy, perf-wise

NOTE:
although modfying

netty/codec/src/main/java/io/netty/handler/codec/compression/ByteBufChecksum.java

Line 35 in e5951d4

abstract class ByteBufChecksum implements Checksum {

by adding a new optimized reflective type seems the right thing, it can hide some subtle potential regressions and behaviours which should be considered, ie

1. new CRC32C is available only after Java >= 9, differently from CRC32 which existing from long time (java 1.1)
2. if we perform Chechsum wrapping via

   netty/codec/src/main/java/io/netty/handler/codec/compression/ByteBufChecksum.java

   Line 106 in e5951d4

   method.invoke(checksum, CompressionUtil.safeNioBuffer(b, off, len));

   , the Method::invoke which piggyback to an invokeinterface (see https://docs.oracle.com/javase/8/docs/api/java/util/zip/Checksum.html) making it no longer bi-morphic because we will have a third JDK Checksum receiver which call the update method, potentially slowing down everyone (I have a solution for that, actually, but is not nide :P ) (- the same problem happen at

   netty/codec/src/main/java/io/netty/handler/codec/compression/ByteBufChecksum.java

   Line 129 in e5951d4

   checksum.update(b, off, len);

   )

[adwsingh]

@franz1981 are you working on this? If not I would be happy to pick up.

[franz1981]

thanks @adwsingh yep, please go ahead, I'm not working on it ATM

[franz1981]

Ping @adwsingh any cycles to work on this?
If not I can give it to another folk which was interested on it

[adwsingh]

Yeah I spent some time last week understanding the issue and making some code changes to test. I can probably pull of a PR by this weekend,