JDK-8214756 : SA should ignore archived java heap objects that are not in use
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-04
  • Updated: 2019-09-05
  • Resolved: 2019-02-25
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 13
13 b10Fixed
Related Reports
Relates :  
JDK-8214712 - Archive Attributes$Name.KNOWN_NAMES
Relates :  
JDK-8230674 - Heap dumps should exclude dormant CDS archived objects of unloaded classes
Description
When archived java heap regions are mapped into a runtime jvm process, archived java objects become alive when they are in use. For example, when a shared class is loaded, its mirror object is materialized and becomes alive. When the class is initialized, its archived subgraphs are  used. For the rest of the objects in the mapped archive heap regions, they are not live objects and stay as 'dormant'. They may not be in a 'consistent' state since their associated Klass may not be loaded yet. SA should ignore those objects when iterating java heap.

Currently, the types of archived java objects are still limited. All archived objects' klasses are already loaded by the time SA walks java heap. With more object subgraphs are being archived, there will be java objects whose klasses are not yet loaded during SA heap iteration. 

With the JDK-8214712 change, the java/util/jar/Attributes$Name.KNOWN_NAMES subgraph is archived. Claes noticed following failure with open/test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java when running the test with his change:

jib > Exception in thread "main" sun.jvm.hotspot.utilities.AssertionFailure: can not get class data for java/util/jar/Attributes$Name0x00000008002779e0
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance(HeapHprofBinWriter.java:949)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(AbstractHeapGraphWriter.java:95)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(ObjectHeap.java:283)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:101)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:443)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:182)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:97)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:326)
jib > 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:455)

The java/util/jar/Attributes and java/util/jar/Attributes$Name classes are not used by the test, so they are not loaded and added to HeapHprofBinWriter.classDataCache map. The AssertionFailure is triggered when HeapHprofBinWriter.write() iterates heap and encounters the archived java/util/jar/Attributes$Name.KNOWN_NAMES.
Comments
Making modifications to ignore objects whose associated classes are unloaded while walking the heap to create a heapdump. Not ignoring these objects while walking the heap for other purposes (like printing out the class histogram) -- it does not look like it is needed to do so. Can be taken up as a separate issue if these objects need to be ignored during heap walking for other purposes.
23-02-2019
[~mgronlun] Thanks a lot for looking into this and confirming it is not an issue for JFR!
04-12-2018
[~jiangli] IIUC this issue appears when attempting heap iteration, like HPROF, that is, not following a live graph, but instead processing the parsable heap directly across the address range. JFR does not do that kind of heap iteration. The memory leak profiler do walks in the heap, but it follows the root set (similar to the GCs), so on this understanding of the problem, there is nothing needed for JFR.
04-12-2018
Hi [~mgronlun] and [~egahlin], do you think JFR would need similar handling for the 'dormant' java objects in the archived heap regions, whose klasses are not yet loaded during heap walking? If needed, I'll create a separate bug or RFE for JFR. Thanks.
04-12-2018