RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs

[Peter Levart]

On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev <shade at 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