RFR: jsr166 jdk9 integration wave 7

[Doug Lea]

Responding to ForkJoinPool reviews (thanks for these!)...

On 06/29/2016 06:41 PM, Martin Buchholz wrote:

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

The choice was between being consistent with the common pool
property vs the ThreadPoolExecutor constructor. The latter
should be easier for users to share configuration across pool
classes, so I used it at the expense of harder-to-decode
parameter specs, but now made a little cleaeer:

>
> On Wed, Jun 29, 2016 at 8:38 AM, Daniel Fuchs <daniel.fuchs at oracle.com
> <mailto:daniel.fuchs at oracle.com>> wrote:

> 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}."
>

Thanks! I added a variant of this sentence.

On 06/29/2016 02:13 PM, Roger Riggs wrote:
> 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...}
>

Thanks!. Done. At least I hope so.
Because of https://bugs.openjdk.java.net/browse/JDK-8136503
we can't run javadoc on pre-integrated sources to check how this came out.


On 06/28/2016 08:55 AM, Paul Sandoz wrote:

> 577      * ... So these explicit checks would exist in some form anyway.
> ...

> The paragraph is referring to explicit checks (null and bounds checks) that
> were removed when the reference to Unsafe was removed.

Thanks. I killed the explicit checks sentence.

-Doug