ForkJoinPool TC underflow issue in JDK 11 and 17 (JDK-8330017)

[Viktor Klang]

Hi George,

I just noticed that my reply never made it to the list.

Thanks for raising awareness of this issue!

Cheers,
√


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: concurrency-discuss <concurrency-discuss-retn at openjdk.org> on behalf of George Lu <george.lu at broadcom.com>
Sent: Friday, 28 February 2025 21:51
To: concurrency-discuss at openjdk.org <concurrency-discuss at openjdk.org>
Subject: ForkJoinPool TC underflow issue in JDK 11 and 17 (JDK-8330017)

Hi all,

There is a known issue (JDK-8330017) in JDK 11 and 17 where the
ForkJoinPool can hang when the Release Count (RC) reaches
ForkJoinPool.MAX_CAP.

This occurs due to an underflow in Total Count (TC) when attempting to
signal for deregisterWorker. Specifically, in JDK 17, the following
line:

    compareAndSetCtl(c, ((UC_MASK & (c - TC_UNIT)) | (prevCtl & SP_MASK))))

When TC == 0, (c - TC_UNIT) underflows, unintentionally decrementing
RC by 1. Notably, TC == 0 is not a rare edge case (since total workers
== parallelism is common), meaning this accidental underflow can occur
frequently. We have encountered this issue in two of our long-running
JVMs. A possible fix is to properly mask TC and RC as follows:

    compareAndSetCtl(c, ((RC_MASK & c) | (TC_MASK & (c - TC_UNIT)) |
(prevCtl & SP_MASK))))

Regards,
George

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/concurrency-discuss/attachments/20250404/b6a4083f/attachment-0001.htm>