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

Peter Levart plevart at openjdk.org
Thu Jul 28 11:23:40 UTC 2022


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

> > > ...I can take this over, unless you want to do it, Aleksey?
> > 
> > 
> > I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be?
> 
> On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and _then_ do any followups that might make the test more targeted.

By removing System.gc() you effectively make the test a NO-OP. It then basically tests just that newly constructed SoftReference is not cleared in the next moment after construction. I would then rather just disable the test until it is fixed properly...

-------------

PR: https://git.openjdk.org/jdk/pull/9533


More information about the core-libs-dev mailing list