RFR: jsr166 jdk9 integration wave 7

[Roger Riggs]

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