RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27]

[Doug Lea]

On Mon, 19 Jan 2026 21:03:02 GMT, Viktor Klang <vklang at openjdk.org> 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