What about a new API multiply method which takes an forkjoinpool, and only if that is used/specified it will use the parallel mode (and only if Notsitzes threshold applies?). Most of the pool tuning can then done with this argument. It also avoids surprise threads.
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von kabutz <d...@openjdk.java.net> Gesendet: Thursday, November 18, 2021 11:41:40 AM An: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3] On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes <dhol...@openjdk.org> wrote: > To add my 2c IMO a parallel version of this type absolutely **must** be > opt-in. There are simply far too many side-effects of using the FJP and > multiple threads to perform the calculation in parallel as if it is just a > minor implementation detail. A clear API is 1000x better than a "kill switch". > > And yes you may still need to expose some kind of tuning knob. > > David Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be necessary. BigInteger has thresholds for using different multiply algorithms and these are also not configurable. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409
