On Thu, 8 Jan 2026 16:51:34 GMT, Viktor Klang <[email protected]> wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change signalWork fencing; in-progress activation changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1961:
>
>> 1959: if (q.base == b) { // else
>> inconsistent
>> 1960: if (t == null) {
>> 1961: if (q.array == a) { // else
>> resized
>
> @DougLea Do we have any good sense of how "far behind" a completed resize a
> worker can end up being (i.e. looking at an array that has been replaced
> already)? I'm just thinking if the rescanning is spending cycles looking at
> the wrong thing.
That loop rereads q.array on each iteration, which means it is never stale.
It's possible ito nstead check for staleness and rescan if so. I just tried a
version with this, but it's not looking any better.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673445481
