On Thu, 8 Jan 2026 18:35:03 GMT, Doug Lea <[email protected]> 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
