On Wed, 16 Oct 2024 16:38:13 GMT, Viktor Klang <vkl...@openjdk.org> wrote:
>> This addresses tendencies in previous update to increase fencing, scanning,
>> and signalling that can increase contention, and slow down performance
>> especially on ARM platforms. It also uses more ARM-friendly constructions to
>> reduce overhead (leading to several changes that all of the same form),
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969:
>
>> 1967: int phase = w.phase, r = w.stackPred; // seed from
>> registerWorker
>> 1968: int cfg = w.config, nsteals = 0, src = -1;
>> 1969: for (;;) {
>
> Could the non-labeled version introduce different GC safepoints which could
> have adverse impacts? 🤔
Yes, one of many uncertainties and tradeoffs...
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2279:
>
>> 2277: if (U.compareAndSetReference(a, k, t,
>> null)) {
>> 2278: q.base = b + 1;
>> 2279: w.source = j;
>
> Might be worth commenting the volatile-write piggybacking which allows to get
> away with not calling updateBase above? 🤔
Thanks; done
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2433:
>
>> 2431: if (U.compareAndSetReference(a, k, t,
>> null)) {
>> 2432: q.base = nb;
>> 2433: w.source = j;
>
> Might be worth commenting the volatile-write piggybacking which allows to get
> away with not calling updateBase above? 🤔
done
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806452514
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806454588
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806454936
