RFR: jsr166 jdk9 integration wave 7

[Daniel Fuchs]

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?
>