RFR: 8336707: Contention of ForkJoinPool grows when stealing works [v29]

Doug Lea dl at openjdk.org
Tue Nov 19 19:15:48 UTC 2024


On Tue, 19 Nov 2024 16:52:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2805:
> 
>> 2803:             }
>> 2804:         }
>> 2805:         return e;
> 
> @DougLea Is there any benefit to using `break` in the loop rather than `return e;` directly?

It's marginal, but the current structure has a single return vs many that could have been done here, leading to simpler flow graph for compiler.. (In some other methods, it's not worth doing.)

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 4082:
> 
>> 4080:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 4081:                     public ForkJoinPool run() {
>> 4082:                         return new ForkJoinPool((byte)0); }});
> 
> @AlanBateman Any recommendation as to what is ideal here with SM removed? /cc @DougLea

I  moved this to end so that in next pass with SM removed, the static init will end with just:
common = new ForkJoinPool((byte)0).
(Which will be sure to be done after all the other static init finiahes.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848915093
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848921820


More information about the core-libs-dev mailing list