JDK-8151460 : Metaspace counters can have inconsistent values
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2016-03-08
  • Updated: 2023-11-21
  • Resolved: 2020-07-30
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 9 Other
9 b115Fixed openjdk8u382Fixed
Related Reports
Duplicate :  
JDK-8153323 - gc/metaspace/TestMetaspacePerfCounters.java fails when synching jdk9/hs with jdk9/dev
Duplicate :  
JDK-8153323 - gc/metaspace/TestMetaspacePerfCounters.java fails when synching jdk9/hs with jdk9/dev
Duplicate :  
JDK-8305848 - [jdk8] gc/metaspace/TestPerfCountersAndMemoryPools.java fails intermittently
Relates :  
JDK-8153410 - Disable tests until JDK-8151460 gets to main
Relates :  
JDK-8163413 - gc/metaspace/TestMetaspacePerfCounters failure
Relates :  
JDK-8251392 - Consolidate Metaspace Statistics
Relates :  
JDK-8153323 - gc/metaspace/TestMetaspacePerfCounters.java fails when synching jdk9/hs with jdk9/dev
Relates :  
JDK-8266183 - Provide an API to get statistics from metaspace in a consistent manner
Description
----------System.err:(19/1162)----------
java.lang.RuntimeException: (assert failed: 7092272 == 7092400)
	at jdk.test.lib.Asserts.error(Asserts.java:447)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:374)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:169)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:152)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:134)
	at TestPerfCountersAndMemoryPools.checkMemoryUsage(TestPerfCountersAndMemoryPools.java:79)
	at TestPerfCountersAndMemoryPools.main(TestPerfCountersAndMemoryPools.java:44)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:804)
Comments
Fix Request (8u): I'd like to backport this change to 8u to reduce the risk of intermittent test failures. Patch does not apply cleanly and in itself is not complete: the test had been modified first in the course of JEP 280 [1], then received this patch. Both parts are needed to stabilize the test. Therefore the fix consists of [1] and this patch (because it is of course not necessary to downport JEP 280 in full). RFR: https://github.com/openjdk/jdk8u-dev/pull/301 Risk: small - test fix only Tests: I manually ran the tests on linux x64 and x86, all succeeded. Ran GHAs. Tried also to artificially induce the original error but without success. [1] https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/2725fdfbc8e5
14-04-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/301 Date: 2023-04-11 14:30:12 +0000
13-04-2023
Okay. Had talked this over with Stefan but I probably misunderstood him, sorry for that.
30-07-2020
[~stuefe], we don't reopen bugs that have integrated patches as you can't reuse them to fix the problem. please open a new bug.
30-07-2020
Still unsolved. The original fix makes the problem more rare but the underlying problem is that the metaspace perf counters are updated one by one without lock protection.
30-07-2020
This is still a problem and can happen sporadically since the Metaspace performance counters are not read under lock protection and may not be consistent: void MetaspaceCounters::update_performance_counters() { if (UsePerfData) { assert(_perf_counters != NULL, "Should be initialized"); _perf_counters->update(capacity(), max_capacity(), used()); } } Between each call to capacity/max_capacity/used, metaspace may be allocated/released concurrently so the counters can get out of sync with each other.
27-07-2020
Bugs found by nightly testing. Verified by passed nightly.
26-07-2017
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/eb591308c2a2 User: lana Date: 2016-04-20 17:53:12 +0000
20-04-2016
Yes, let's exclude the test in main.
04-04-2016
will that be ok to exclude this test in main until this change reaches there?
04-04-2016
You should have pusedh that to main,as that's blocking the synching with jdk9/dev
04-04-2016
URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/eb591308c2a2 User: sjohanss Date: 2016-04-04 11:34:47 +0000
04-04-2016
I tried to push a fix for this before going on vacation, but the push failed due to: JDK-8152586 Now pushing again so the fix should be in the hs-rt repo shortly.
04-04-2016
Just filed JDK-8153323, which seems to be related to this, so I'm raising the priority to 1, as this is blocking the synching of jdk9/hs with jdk9/dev
01-04-2016
This test was changed as part of the Indify Strings Integration (JDK-8148483). In that test one System.gc() call was removed because it was seen as unnecessary, but when running with -Xcomp it seems to be needed. I will create a patch adding back the System.gc() call.
21-03-2016
This problem has been seen with two tests: gc/metaspace/TestMetaspacePerfCounters.java gc/metaspace/TestPerfCountersAndMemoryPools.java Both tests check the consistency of counters related to metaspace and the compressed class space. These counters are used only by the GC, so I suspect this problem to be GC related. Can the GC team please investigate?
18-03-2016