On May 17, 2013, at 3:45 PM, David Chase <david.r.ch...@oracle.com> wrote:
> > On 2013-05-17, at 4:28 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > >> >> On May 17, 2013, at 12:09 AM, David Chase <david.r.ch...@oracle.com> wrote: >> >>> >>> On 2013-05-16, at 5:27 PM, Alan Bateman <alan.bate...@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.
