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 Contemplating how this test could be fixed without using WhiteBox gc testing... The test could wrap the cached instance with a WeakReference as it does now (ref1) and then have a second WeakReference that would wrap an instance of "new Object()", (ref2)... Then the test coul gradually allocate more and more heap in a loop, checking both WeakReference(s) as it goes. When ref2 is cleared but ref1 is not, the test would succeed. Any other outcome ( such as both refs being cleared at the same point) could be considered a failure. This would assume that GCs would 1st clear XxxReferences of weakly reachable referents and only much later those of softly reachable. I hope this property is universal to all GCs although it is not guaranteed by the spec. ------------- PR: https://git.openjdk.org/jdk/pull/9533
