Hi,
Several constructors of ForkJoinPool are modified with comments like "
using defaults for all other parameters".
However, there there are no other parameters in each constructor in
question.
It seems to imply a reference to the new full function constructor, that
reference should be explicit
complete with a {@link...}
$.02, Roger
On 6/29/2016 11:38 AM, Daniel Fuchs 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?
