Hi,
since this looks like a suggestion for a change to the libraries
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
core-libs-dev mailing list.
Hth,
Thomas
On 07.02.24 15:20, Frank Kretschmer wrote:
Hi Java GC-experts,
I'm facing an interesting G1 garbage collector observation in OpenJDK
17.0.9+9, which I would like to share with you.
My application runs many asynchronous tasks in a fixed thread pool,
utilizing its standard LinkedBlockingQueue. Usually, it generates just a
little garbage, but from time to time, I observed that the survivor
spaces grow unexpectedly, and minor collection times increase.
This being the case, many
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
instances can be found on the heap. In fact, the whole heap (rank 1 as
shown in jmap) was filled up with ConditionNode instances after a while.
After some tests, I figured out that G1 seems to be able to collect
“dead” ConditionNode instances during minor collections only if no
formerly alive ConditionNode instances were promoted to the old
generation and died there.
To illustrate that, I've attached a “G1LoiteringConditionNodes” class
that can be run for demo purposes, e.g. under Linux with OpenJDK
17.0.9+9 (VM options see comments within the class), and its gc-log
output. It shows that during the first two minutes, everything is fine,
but after a promotion to the old generation, survivors grow and minor
pause time increase from 3 to 10ms.
For me, it looks like an issue similar to
https://bugs.openjdk.org/browse/JDK-6805775 “LinkedBlockingQueue Nodes
should unlink themselves before becoming garbage”, which was fixed in
OpenJDK 7.
What’s your opinion about that? Wouldn’t it be worth to enable G1 to
collect those AbstractQueuedSynchronizer$ConditionNode instances during
minor collections, as it is done for LinkedBlockingQueue Nodes?
Best regards
Frank Kretschmer, Java Realtime Application Developer
