On Mon, 19 Jan 2026 21:03:02 GMT, Viktor Klang <[email protected]> wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify scan mode control by moving and reworking topLevelExec and
>> throwing on trim
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1271:
>
>> 1269: }
>> 1270: if (pred == null && pool != null)
>> 1271: pool.signalWork(this, s); // may have appeared
>> empty
>
> @DougLea I presume we don't need to do the getReferenceAcquire if the pool is
> null?
>
> If so, then we could do something like:
>
>
> boolean signal = pool != null && U.getReferenceAcquire(a,
> slotOffset(m & (s - 1))) == null;
> if (unlock != 1) { // release external lock
> U.putInt(this, PHASE, unlock);
> U.storeFence();
> }
> if (signal)
> pool.signalWork(this, s); // may have appeared empty
I was skeptical about specializing around here, but after reading this, I found
that avoiding getAcquire when already known empty was s small win.
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1303:
>
>> 1301: if (unlock != 1)
>> 1302: phase = unlock;
>> 1303: if (pool != null)
>
> @DougLea Are we 100% sure we always need to signal upon resize?
Yes, because worker in runWorker won't see a task and so won't propagate (and
it costs more to check this than just always doing it on resize).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779750895
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779755766