One more round… Re: RFA 8056248: Improve ForkJoin thread throttling

[Seán Coffey]

Paul,

I see that a re-submitted CCC request is still pending approval. Are you 
sharing more up to date information below ? Any new system property 
needs to be passed through the CCC process.

Can we await the decision on that before proceeding with push approval ?

regards,
Sean.

On 16/09/2014 12:12, Paul Sandoz wrote:
> Hi,
>
> The CCC for the use of the sys prop within the java namespace was rejected (for good reason, even if there are already existing cases). I don't want to rename the property and deal with the 8 vs. 9 differences.
>
> So i propose to go back to the original proposal:
>
> diff -r a6403166fc7f src/share/classes/java/util/concurrent/ForkJoinPool.java
> --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java	Fri Sep 05 10:54:28 2014 +0200
> +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java	Fri Sep 05 11:26:49 2014 +0200
> @@ -143,9 +143,6 @@
>   * - the class name of a {@link ForkJoinWorkerThreadFactory}
>   * <li>{@code java.util.concurrent.ForkJoinPool.common.exceptionHandler}
>   * - the class name of a {@link UncaughtExceptionHandler}
> - * <li>{@code java.util.concurrent.ForkJoinPool.common.maximumSpares}
> - * - the maximum number of allowed extra threads to maintain target
> - * parallelism (default 256).
>   * </ul>
>   * If a {@link SecurityManager} is present and no factory is
>   * specified, then the default pool uses a factory supplying
>
> Under duress i can also modify the code to remove the property, but i really would prefer to keep changes to an absolute minimum to ease any future backporting.
>
> Paul.
>
>
> On Sep 11, 2014, at 2:37 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>
>> Hi,
>>
>> After some off-list discussion and contemplation a implementation note is considered the best way forward (a middle ground between saying nothing and updating the spec).
>>
>> Here are the proposed doc updates for review to 8u (which requires a CCC) that would be applied on top the the 9 patch:
>>
>> diff -r 7b40710067fa src/share/classes/java/util/concurrent/ForkJoinPool.java
>> --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java	Fri Sep 05 10:54:28 2014 +0200
>> +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java	Thu Sep 11 14:35:00 2014 +0200
>> @@ -143,9 +143,6 @@
>>   * - the class name of a {@link ForkJoinWorkerThreadFactory}
>>   * <li>{@code java.util.concurrent.ForkJoinPool.common.exceptionHandler}
>>   * - the class name of a {@link UncaughtExceptionHandler}
>> - * <li>{@code java.util.concurrent.ForkJoinPool.common.maximumSpares}
>> - * - the maximum number of allowed extra threads to maintain target
>> - * parallelism (default 256).
>>   * </ul>
>>   * If a {@link SecurityManager} is present and no factory is
>>   * specified, then the default pool uses a factory supplying
>> @@ -162,6 +159,15 @@
>>   * pools with greater than the maximum number result in
>>   * {@code IllegalArgumentException}.
>>   *
>> + * <p>This implementation supports an additional common pool parameter that may
>> + * be controlled by setting the following
>> + * {@linkplain System#getProperty system property}:
>> + * <ul>
>> + * <li>{@code java.util.concurrent.ForkJoinPool.common.maximumSpares}
>> + * - the maximum number of allowed extra threads to maintain target
>> + * parallelism (default 256).
>> + * </ul>
>> + *
>>   * <p>This implementation rejects submitted tasks (that is, by throwing
>>   * {@link RejectedExecutionException}) only when the pool is shut down
>>   * or internal resources have been exhausted.
>>
>> Paul.
>>
>> On Sep 5, 2014, at 11:35 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to backport the improvements to the fork join framework from 9 to 8u40:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028419.html
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8056248
>>>
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8056248-fj-thread-throttling/webrev/
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7af64e3e095d
>>>
>>> The changeset (when shuffled) imports cleanly into jdk8u-dev/jdk.
>>>
>>> However, it also introduced a new system property ("java.util.concurrent.ForkJoinPool.common.maximumSpares"). I am not sure if we can add such a new feature to an 8u release, any advice? If that is not possible I suggest that reference to that property be removed from the JavaDoc, since that makes it easier to support further backports:
>>>
>>> diff -r a6403166fc7f src/share/classes/java/util/concurrent/ForkJoinPool.java
>>> --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java	Fri Sep 05 10:54:28 2014 +0200
>>> +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java	Fri Sep 05 11:26:49 2014 +0200
>>> @@ -143,9 +143,6 @@
>>> * - the class name of a {@link ForkJoinWorkerThreadFactory}
>>> * <li>{@code java.util.concurrent.ForkJoinPool.common.exceptionHandler}
>>> * - the class name of a {@link UncaughtExceptionHandler}
>>> - * <li>{@code java.util.concurrent.ForkJoinPool.common.maximumSpares}
>>> - * - the maximum number of allowed extra threads to maintain target
>>> - * parallelism (default 256).
>>> * </ul>
>>> * If a {@link SecurityManager} is present and no factory is
>>> * specified, then the default pool uses a factory supplying
>>>
>>>
>>> Thanks,
>>> Paul.