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

[David Chase]

On 2013-05-17, at 12:13 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On May 17, 2013, at 4:45 PM, David Chase <david.r.chase at oracle.com> wrote:
> 
>> That is, turning the parallelism option into a static choice of method name is not a good way to go; it only works for programming in the small, and in general does not remove the need for the system-properties knob.
> 
> I agree it does not obviate the need for an external controlling mechanism.
> 
> The static approach also signals programmer intent. Note that for the Stream API there are further reasons for the explicitness (switching from sequential to parallel is not always transparent in terms of the results produced).

Different results is not an issue for CRC and Adler.

> I disagree the default should be parallel (conservative or otherwise) since it can change the usage of compute resources from one release to the next, perhaps in ways that are unpredictable and hard to figure out why.

History is rhyming.  I've heard much the same said of GC, caches, virtual memory, and threads.  I'm all for conservative default settings for the FJ pool, and if we need a few rarely used parallelism kill switches for hard cases, I think that's acceptable.  Proliferating interfaces and forcing programmers to make uninformed static choices about parallelism is not a good plan.

> That is arguably distributive for a new platform release and even more so for an update release of 7.

The forkjoin work won't backport to 7 because it uses that System FJ pool, so that's not an issue, and the accelerated CRC only backports if we keep the ugly assembly language, because 7 builds with old compilers.  I would hope to get rid of that assembly language if we move forward to gcc 2.6, Clang, SolStudio 12.3, and VS 2012.  They all claim to support the intrinsics, though at least one of those compilers has bugs that need fixing.

David