I agree the ForkJoinPool docs are difficult to understand.
It's not immediately obvious that the maximumPoolSize of a user-constructed
pool is effectively unlimited, but the maximumPoolSize of the common pool
is availableProcessors + maxSpares.
It may be better if the common pool and other pools are configured the same
way, by having a maxSpares parameter instead of a maximumPoolSize
parameter.
(Using availableProcessors to size thread pools will increasingly become a
resource usage problem)
On Wed, Jun 29, 2016 at 8:38 AM, Daniel Fuchs <daniel.fu...@oracle.com>
wrote:
> Hi Martin,
>
> I was looking at the new constructor's API documentation
> in ForkJoinPool - and somehow got confused by the sentence:
>
> 2235 * @param maximumPoolSize [...
> 2241 * ...] To
> 2240 * arrange the same value as is used by default for the common
> 2241 * pool, use {@code 256} plus the parallelism level.
>
> I mean - this looks bizarre, until you understand that the
> common pool has a maxSpares of 256 - which means that its
> actual max core pool size is 256 + parallelism level
> (am I getting that part right?).
>
> I wonder if it would be worth expanding on the rationale
> for that value?
>
> I mean something like: "The maximum number of spare threads
> used by the common pool is 256: to arrange the same value as is
> used by default for the common pool, use {@code 256} plus the
> parallelism level for {@code maximumPoolSize}."
>
> best regards,
>
> -- daniel
>
>
>
>
> On 27/06/16 20:38, Martin Buchholz wrote:
>
>> jsr166 has been pervasively modified to use VarHandles, but there are some
>> other pending changes (that cannot be cleanly separated from VarHandle
>> conversion). We expect this to be the last feature integration for jdk9.
>>
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>>
>> We're asking Paul to do most of the review work here, as owner of
>> VarHandles JEP and as Oracle employee.
>> We need approval for API changes in
>>
>> https://bugs.openjdk.java.net/browse/JDK-8157523
>> Various improvements to ForkJoin/SubmissionPublisher code
>>
>> https://bugs.openjdk.java.net/browse/JDK-8080603
>> Replace Unsafe with VarHandle in java.util.concurrent classes
>>
>> There is currently a VarHandle bootstrap problem with
>> ThreadLocal/AtomicInteger that causes
>> java/util/Locale/Bug4152725.java
>> to fail. Again I'm hoping that Paul will figure out what to do. In the
>> past rearranging the order of operations in <clinit> has worked for
>> similar
>> problems. It's not surprising we have problems, since j.u.c. needs
>> VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably
>> AtomicInteger and ConcurrentHashMap) to do work. Maybe we need some very
>> low-level concurrency infrastructure that does not use VarHandles, only
>> for
>> bootstrap?
>>
>>
>
