On Thu, 6 Aug 2026 23:17:57 GMT, Shiv Shah <[email protected]> wrote: >> The test fails intermittently with OutOfMemoryError under -Xcheck:jni >> -XX:+UseZGC (the original report also had -XX:+ZGenerational, which is gone >> since JEP 490). Reproduced at about 2%: 6 of 300 runs on four 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 sampling >> agent holds jweaks on the sampled objects, which keeps the transient garbage >> alive until a major collection runs. The test's actual live set is only >> about 20MB. >> >> Fix: bump the test heap from 512m to 1g. >> >> Testing: 500 default-config runs at 1g all pass. The failing configuration >> at 1g (501 runs) had 2 OOME failures, about 0.4% vs 2% at 512m. >> >> >> >> --------- >> - [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
pulled the gc logs from the two 1g failures. the majors did run but reclaimed almost nothing right before the OOMs GC(4) Major Collection (Allocation Stall) 1024M >> 1024M 2.424s Out Of Memory (Allocator0) GC(4) Major Collection (Allocation Stall) 1024M >> 1018M 2.419s Out Of Memory (Allocator3) three majors completed before the first internal OOM in both runs, seven or eight before the java OOME. later majors in the same runs reclaim fine, 1024M >> 682M and 1024M >> 272M, but the allocators already got OOM by then ------------- PR Comment: https://git.openjdk.org/jdk/pull/32229#issuecomment-5257586245
