RFR JDK-6321472: Add CRC-32C API

[David Chase]

On 2014-10-17, at 2:53 PM, Staffan Friberg <staffan.friberg at oracle.com> wrote:

> Fully agree that using Unsafe makes one sad.
> 
> I'm just about to send out a new webrev with Alan's and Peter's comments, once I have that done I will give using the NIO-Buffer API a second try to see if using IntBuffer and LongBuffer is able to achieve similar performance.
> 
> As I noted in my reply the second goal after adding this API will is to create intrinsics that make use of the crc32c instructions available on both x86 and SPARC which will bump the performance even further. So one thing I try to do is make sure the implementation makes it easy to do that without having to completely rewrite it again.

I’d like to review this, but it will take me a little bit of time.
Recall that I did a lot of work on CRC for Intel to take advantage
of the carryless multiply instructions for CRC32.

Reading the comments, if I understand this properly, the difference between
CRC32 and CRC32C is that CRC32C is just the bit or byte flip of CRC32 as
we currently compute it.   If so, wouldn’t it make more sense to not reinvent
that rather tricky wheel?  The code you have carefully written will run substantially
slower than CRC32 on recent Intel hardware (Haswell and newer in particular)
because there an intrinsic is already substituted.

Can you verify whether this bit/byte flipping equivalence holds, or not?

If we were interested in true peak performance, we’d also investigate
fork/join parallelism; I did this once and it worked just fine if you made the
block sizes large enough.

David