On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example > Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test > TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java > TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under > pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what > happens with weak references. As seen with other GCs, they can clear the > weakrefs on Full GC. In fact, the test fails with G1 if we do a second > System.gc() in this test. So the test itself is flaky. The fix is to avoid > doing `System.gc()` altogether in that subtest. The test is still retained to > see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 > repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 > repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 > repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 > repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 > repetitions > > WhiteBox has a number of methods that allow better control over GC, e.g. > > fullGC(), concurrentGCRunToIdle(), etc. Would that help? > > I think the test relies on assumption that `System.gc()` does the weak > reference clearing. Which is not given, for example if concurrent GC cycle is > triggered without weak refs processing. I don't think we can solve this with > GC control, unless we hack into the each of the GC's policies with Whitebox... Well, WB GC control can run concurrent GC, and wait until certain control points are reached or conc cycle is finished. An example that does that and checks referents get cleared is: test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java TBH, not certain how GC policies play into that, and how well WB is supported in each GC. Might be worth trying? Other that that, how does removinch System.gc() help make the test more reliable? ------------- PR: https://git.openjdk.org/jdk/pull/9533
