JDK-6966967 : G1: SA: jmap and jstack do not work
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs17,hs20,6u25-rev
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-07-06
  • Updated: 2013-10-04
  • Resolved: 2011-09-26
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.
Other
hs22Resolved
Related Reports
Duplicate :  
JDK-7059019 - G1: add G1 support to the SA
Duplicate :  
JDK-7040035 - jmap_permstat_basic_forName_core: CollectedHeap instead of GenCollectedHeap or ParallelScavengeHeap
Relates :  
JDK-7041931 - Document 6966967 as a known issue in JDK7
Relates :  
JDK-6946385 - G1: jstat does not support G1 GC
Relates :  
JDK-7075646 - G1: fix inconsistencies in the monitoring data
Relates :  
JDK-6946417 - G1: Java VisualVM does not support G1 properly.
Description
jmap does not work with G1:

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at sun.tools.jmap.JMap.runTool(JMap.java:179)
	at sun.tools.jmap.JMap.main(JMap.java:110)
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: Expecting GenCollectedHeap or ParallelScavengeHeap, but got sun.jvm.hotspot.gc_interface.CollectedHeap
	at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
	at sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:592)
	at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:249)
	at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51)
	at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:416)
	at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:56)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
	at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)
Comments
PUBLIC COMMENTS We have resolved the jmap issues after adding Serviceability Agent support to G1, with: 1) 7059019: G1: add G1 support to the SA Also, jstat now works with G1 since this CR was pushed: 2) 6946417: G1: Java VisualVM does not support G1 properly and also after pushing some extra fixed for jstat: 3) 7075646: G1: fix inconsistencies in the monitoring data 1) and 3) with into hs23 but we are expecting them to be transplanted to hs22. I'm closing this as a dup (I arbitrarily chose the first CR to put in the Duplicate Of field).
26-09-2011
EVALUATION The SA work to get jmap to work with G1 is being done as part of 7059019. The work to get a few inconsistencies in the jstat data resolved is being done as part of 7075646. These two should resolved the issues reported in this CR. If they do, we'll close this as a dup.
12-08-2011
EVALUATION The failure happens in the sun.jvm.hotspot classes which are used by jmap and jstack. It looks as if there is some HotSpot functionality mirrored in Java classes in that package and it has not been extended to know about the G1CollectedHeap. This is a serviceability issues, so I'm re-assigning the CR accordingly.
20-08-2010