JDK-8283276 : java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 11,17,19,20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-03-16
  • Updated: 2025-07-10
  • Resolved: 2022-08-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 19 JDK 20
17.0.12-oracleFixed 19Fixed 20 b10Fixed
Related Reports
Relates :  
JDK-8277072 - ObjectStreamClass caches keep ClassLoaders alive
Description
Test passes fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc:

$ 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)

This is probably because System.gc() request in the test is handled by different GCs differently.

In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. We should probably stop doing GCs altogether there.
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1645 Date: 2023-08-08 00:27:51 +0000
08-08-2023
Fix request (17u) Clean backport. The fix for a tesbug.. Review 17u-dev: https://github.com/openjdk/jdk17u-dev/pull/1645
08-08-2023
Changeset: 4b3dfe1d Author: Peter Levart <plevart@openjdk.org> Date: 2022-08-04 16:53:57 +0000 URL: https://git.openjdk.org/jdk/commit/4b3dfe1d22f7fed8a408ee50343d52cf1ac481ef
05-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/162 Date: 2022-08-04 13:38:08 +0000
04-08-2022
Changeset: d4a795d7 Author: Peter Levart <plevart@openjdk.org> Date: 2022-08-04 13:25:15 +0000 URL: https://git.openjdk.org/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a
04-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9684 Date: 2022-07-29 09:05:53 +0000
29-07-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9533 Date: 2022-07-18 07:40:53 +0000
18-07-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/27 Date: 2022-06-16 08:08:15 +0000
16-06-2022
In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. We should probably stop doing GCs altogether there.
16-06-2022
This test keeps failing for me in testing, taking over.
16-06-2022
Roman, please take a look?
16-03-2022