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

[Viktor Klang]

On Thu, 8 Jan 2026 18:35:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> 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.

Yeah, I was just thinking that the `array`-field is non-volatile so a read isn't guaranteed to yield anything new unless that read is piggybacking on some other fence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2674233841