JDK-6987597 : ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: hs19,7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-09-27
  • Updated: 2014-04-07
  • Resolved: 2013-11-28
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 8
8 b120Fixed
Related Reports
Duplicate :  
JDK-7049125 - java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java fails with JDK7 b143
Duplicate :  
JDK-7049132 - com/sun/management/GarbageCollectorMXBean/LastGCInfo.java fails with JDK7 b143
Relates :  
JDK-7036199 - Adding a notification to the implementation of GarbageCollectorMXBeans
Description
ManagementFactory.getGarbageCollectorMXBeans() returns an empty list when Java started with -XX:+UseConcMarkSweepGC. JDK is 7 b110.
Here is a snippet from a Solaris SPARC Client VM -Xmixed failure
of LastGCInfo.java:

----------System.err:(13/706)----------
java.lang.RuntimeException: No GcInfo returned
	at LastGCInfo.main(LastGCInfo.java:59)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:729)

JavaTest Message: Test threw exception: java.lang.RuntimeException: No GcInfo returned
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: No GcInfo returned
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: No GcInfo returned


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: No GcInfo returned


Here is the URL for the failing config:

http://vmsqe.russia/execution/results/JDK7/PROMOTION/VM/7/b110/ConcMarkSweepGC/javase/solaris-sparc/client/mixed/solaris-sparc_javase_client_mixed_JT_JDK_com_sun_management/analysis.html
Here is a snippet from a Solaris SPARC Client VM -Xmixed failure
of GcInfoCompositeType.java:

----------System.out:(8/395)----------
Testing java.lang:type=GarbageCollector,name=ParNew
Items at start: [startTime, id, duration, memoryUsageBeforeGc, memoryUsageAfterGc, endTime]
No type-specific items
Value of attribute null
Testing java.lang:type=GarbageCollector,name=ConcurrentMarkSweep
Items at start: [startTime, id, duration, memoryUsageBeforeGc, memoryUsageAfterGc, endTime]
No type-specific items
Value of attribute null
----------System.err:(13/715)----------
java.lang.Exception: No MXBeans were tested
	at GcInfoCompositeType.main(GcInfoCompositeType.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:729)

JavaTest Message: Test threw exception: java.lang.Exception: No MXBeans were tested
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.Exception: No MXBeans were tested
result: Failed. Execution failed: `main' threw exception: java.lang.Exception: No MXBeans were tested


test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: No MXBeans were tested


Here is the URL for the failing config:

http://vmsqe.russia/execution/results/JDK7/PROMOTION/VM/7/b110/ConcMarkSweepGC/javase/solaris-sparc/client/mixed/solaris-sparc_javase_client_mixed_JT_JDK_java_lang/analysis.html
Comments
Review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013225.html
20-11-2013
SUGGESTED FIX The tests could be modified by adding a delay between the call the System.gc() and the time they try to get a GcInfo object but it won't be reliable as there's no way to know how long the GC cycle will take. A reliable fix could be done after the integration of CR 7036199 "Adding a notification to the implementation of GarbageCollectorMXBeans". The tests could invoke System.gc(), wait for the "end of GC" notification and then get the GcInfo object.
20-04-2011
EVALUATION Both failures are due to test bugs. The two tests proceed the same way and then have the same bug: they invoke System.gc() and then use the GarbageColletorMXBean to get an instance of GcInfo. The problem is that when System.gc() returns, there's no guarantee that the GC has completed its work. The assumption that the GC cycle has been completed is true for stop-the-world GCs but might or might not be true for concurrent GCs (like CMS). If no GC cycle has been completed yet the GcInfo object cannot be created because the VM has no data to fill its fields. This situation can only occur between the start of the VM and the end of the first GC cycle. It is handled by the code below in /jdk/src/share/native/sun/management/GcInfoBuilder.c: jmm_interface->GetLastGCStat(env, gc, &gc_stat); if (gc_stat.gc_index == 0) { if (gc_stat.gc_ext_attribute_values != NULL) { free(gc_stat.gc_ext_attribute_values); } return 0; } This is the only case where the GcInfo can be NULL. Other error situations lead to exception throwing. And after the end of the first GC cycle, the VM will always fill the GcInfo object with data from the latest GC. The test bug remained hidden for a long time but has been revealed with changes related to CR 6692906 "CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time". The modification in CMS makes mutator threads (including the test thread) to run concurrently with CMS worker threads. The consequence is that the test thread is now more likely to try to get a GcInfo object before the end of the CMS GC cycle, leading to a test failure if the returned GcInfo is NULL.
20-04-2011
EVALUATION It is an important functionality
15-12-2010