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 3:45 PM, David Chase <david.r.chase at oracle.com> wrote:

> 
> On 2013-05-17, at 4:28 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> On May 17, 2013, at 12:09 AM, David Chase <david.r.chase at oracle.com> wrote:
>> 
>>> 
>>> On 2013-05-16, at 5:27 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods?
>>> 
>>> I'm not sure I understand.  
>> 
>> Alan may be suggesting that the caller should explicitly, but unobtrusively, opt in to parallel execution rather than it being something implicit. 
> 
> Right, but I was responding to this in the context of a compiler bug -- they just wanted CRC32 and Adler32 to go faster, and were not asking for a new interface.  My intent/assumption was that if I used the System forkjoin pool for this, that if there were a problem with what I might call "obnoxious parallelism", that the person running the application would turn down the parallelism in the system fork-join pool.  If we use forkjoin to make other things go faster (e.g., BigInteger arithmetic and/or formatting) they'll have exactly the same problem, and either they'll have to independently try to deal with it there (in the same way that I worry about whether the CRC/Adler code should be self-throttling) or assume that it will be solved by the same knob being turned (by whoever is tuning the whole application).
> 
> 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.


> Another option is to keep an interface, but add a system property enabling or disabling it.  I'm not sure that's the right approach; there is a sun. property that I use to check the tuning, but as soon as FJ is widely used (and perhaps statically baked in to some larger modules, even if we adopt the ask-for-parallel method idiom), those selective-disable properties will multiply like bunnies, and I don't think that's a good idea (documentation, testing, arrgh).
> 

The parallelism of the F/J common pool in JDK 8 can be configured via system property. Ironically for EE environments probably the simplest thing to do is configure it so that there is no parallelism.

Perhaps there needs to be some -X flags for java/javac to explicitly enable the use of F/J in the JDK for the case where explicit API control is not possible or suitable?

Paul.