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