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.fu...@oracle.com
<mailto:daniel.fu...@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
