On Thu, 8 Jan 2026 16:47:08 GMT, Viktor Klang <[email protected]> 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 1830:
>
>> 1828: */
>> 1829: final void signalWork(WorkQueue q, int qbase) {
>> 1830: int pc = U.getIntAcquire(this, PARALLELISM);
>
> I like this, as this has the nice benefit of seeing potential changes to
> `parallelism` sooner.
It's now back to being fresh upon entry, but not upon retries, mainly because
retires are now less frequent.
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1855:
>
>> 1853: break;
>> 1854: if (c == (c = ctl) &&
>> 1855: c == (c = U.compareAndExchangeLong(this, CTL, c, nc)))
>> {
>
> Are there any measurable differences between the above and `c == (c = ctl) &&
> U.compareAndSetLong(this, CTL, c, nc)` or `c ==
> U.compareAndExchangeLong(this, CTL, c, nc)`? 🤔
It depends on whether there is much contention and/or much filtering. I redid
some of it to take a middle ground on this, and results seems almost always
better. (Which made me realized that I should reconsider a few other
constructions elsewhere.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679952355
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679948199
