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

[Paul Sandoz]

On May 17, 2013, at 4:45 PM, David Chase <david.r.chase at oracle.com> wrote:

> 
> On 2013-05-17, at 10:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision?
>>> 
>> 
>> Right. i.e. it's not the responsibility of solely the JDK to make the decision.
> 
> I don't think I explained my point well enough.  There are two ways that this choice can not be the JDK's decision.  The choice can be made as a system property setting, externally.  Or the choice can be made by the programmer, when they choose, statically and for all uses of their code, to run either in serial or parallel.
> 
> Suppose we decide that it is a static choice.  If I write some package of intermediate size that performs sorts and CRCs and perhaps BigInteger arithmetic, I must choose.  If I choose serial, it never runs faster, if I choose parallel, then my clients may discover that my choice causes problems for them, and they need to set the system property anyway.
> 
> 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).


>  We get all the burdens of extra interfaces, but little win, maybe even a net loss in larger and more complex systems.  The default should be parallel, the default parallel settings should be somewhat conservative but not fully serial, and people will tune if it is necessary.
> 

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. That is arguably distributive for a new platform release and even more so for an update release of 7.

Paul.