On Thu, 6 Aug 2026 23:17:57 GMT, Shiv Shah <[email protected]> wrote: >> The test failed intermittently with OutOfMemoryError under -Xcheck:jni >> -XX:+UseZGC (originally reported with -XX:+ZGenerational, which no longer >> exists after JEP 490). Reproduced on current builds at a stable 2% rate: 6 of >> 300 runs on four different hosts, all with the original signature. >> >> GC logs from the failing runs show the 512m heap reaching 100% with ZGC in >> back-to-back allocation-stall collections that reclaim almost nothing, >> ending in the OOME while Allocator.helper grows its list. The test's live >> set is only about 20MB - five threads that each retain one ~2MB list and >> build one more - so the heap fills with garbage the in-flight concurrent >> cycle cannot yet prove dead: allocation outpaces concurrent collection at >> this heap size, with the sampling agent and -Xcheck:jni overhead on top. It >> is not a leak: the workload is bounded by construction, and the agent stores >> sampled objects via JNI weak global refs only (libHeapMonitorTest.cpp). >> >> So I try to fix this by raise the test heap from -Xmx512m to -Xmx1g to give >> the concurrent >> collector headroom, and add the bug id to @bug. >> >> Testing: 500 repeats of the failing configuration (-Xcheck:jni -XX:+UseZGC, >> linux-x64-debug) all pass, where the 2% rate would have predicted about 10 >> failures; 100 repeats of the default configuration all pass. A gc-logged run >> recording peak occupancy against the new limit is in progress; I'll post the >> number here. >> >> >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Shiv Shah has updated the pull request incrementally with one additional > commit since the last revision: > > Remove bug tag and update copyright year
> GC logs from the failing runs show the 512m heap reaching 100% with ZGC in > back-to-back allocation-stall collections that reclaim almost nothing Given the structure of the test this doesn't seem right to me. We only have 5 threads and then don't allocate very much before creating garbage, so the GC passes should be reclaiming plenty. Does this only occur with ZGC? I would like to get the ZGC developer's take on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32229#issuecomment-5211458656
