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

[Doug Lea]

On Thu, 8 Jan 2026 16:51:34 GMT, Viktor Klang <vklang at openjdk.org> 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