<div dir="ltr"><div>Hello Core Libs Dev Team,<br><br>This is my first time posting here. Please let me know if there are any<br>conventions I should follow.<br><br>I am writing in the hope to get some help to understand a state of the<br>ForkJoinPool that we observed. We have encountered a case where there were tasks<br>inside the queue of the ForkJoinPool, but there was no ForkJoinWorkerThread to<br>execute them. I am wondering if such state is expected of the ForkJoinPool and<br>hopefully I could get some suggestion to understand how our system entered such<br>state.<br><br>Here is the full background. One of our process experienced an OOME and a heap<br>dump was obtained. We know there was a concurrent issue of our system happening<br>on some other machines such that network failure and retries occurred in this<br>process at the same time. Upon analyzing the heap dump, we observed a lot of<br>our network connection handlers being frequently created and terminated which<br>is expected due to the network failure and retry attempts mentioned above.<br>However, those terminated handlers are not being GC'ed because of there were<br>references to tasks submitted to the ForkJoinPool during the connection<br>attempts. The tasks stayed in the queue until OOME happened as there is no<br>threads to execute them.<br><br>From both the heap dump and the thread dump, it seems there was no<br>ForkJoinWorkerThread which, from my understanding, is the worker thread object<br>to execute those tasks. Looking at the ForkJoinPool, I noticed that the ctl<br>field was 9223372032559808512 or 0x7fff ffff 00000000. Is this a valid ctl<br>state? From the code, this ctl field (together with mode = 1) seems to mean<br>a released thread count of 32768 and a total thread count of 0 which seems<br>weird to me because with my current understanding, the total thread count<br>should be larger than the released thread count. This also seems to cause the<br>signalWork method not creating any new thread, since ctl is positive which<br>seems to reflect the fact that new threads are not being created while there<br>were tasks in the queue. Perhaps there are some exceptions that we should catch<br>but did not pay attention to which caused this state?<br><br>Currently, we do not know how to reproduce this issue. Sorry about that. The<br>heap dump is about 1G in size and therefore, it is not very convenient to<br>attach in the email, but here are some information I collected from the heap<br>dump.<br><br>Summary info:<br><br>``````<br>System : Linux(5.4.17-2136.325.5.1.el7uek.x86_64)<br>Architecture: amd64 64bit<br>Java Version: 17.0.4.1 2022-08-18 LTS<br>Java Name: Java HotSpot(TM) 64-Bit Server VM (17.0.4.1+1-LTS-2, mixed mode, sharing)<br>Java Vendor: Oracle Corporation<br>``````<br><br>ForkJoinPool#common states:<br><br>``````<br>ctl: 9223372032559808512<br>saturate: null<br>ueh: null<br>factory: java.util.concurrent.ForkJoinPool$DefaultCommonPoolForkJoinWorkerThreadFactory<br>workerNamePrefix: null<br>termination: null<br>registrationLock: java.util.concurrent.locks.ReentrantLock<br>queues: java.util.concurrent.ForkJoinPool$WorkQueue[]<br>mode: 1<br>bounds: 16777216<br>threadIds: 32768<br>scanRover: 0<br>stealCount: 10912<br>keepAlive: 60000<br>``````<br><br>ForkJoinPool#common#queue[0] states:<br><br>``````<br>nsteals: 0<br>source: 0<br>top: 32304<br>owner: null<br>array: java.util.concurrent.ForkJoinTask[]<br>base: 10912<br>config: 2027939556<br>stackPred: 0<br>phase: -1<br>``````</div><div><br></div><div>The thread dump is attached.<br><br>Please let me know if you need anything else.<br></div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Xiao Yu</div></div></div>