Bug ID: JDK-8081323 ConstantPool::_resolved_references is missing in heap dump

Versions (Unresolved/Resolved/Fixed)

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 10	JDK 8
10 b31Fixed	8u192Fixed

ConstantPool::_resolved_references is missing in heap dump. 
It manifests as unreachable Object[] arrays when you browse the heap dump.

The problem is there again after JDK-8059340 backout (JDK-8081320).

Attempt to move the field from ConstantPool to klass mirror failed (doesn't work well with class redefinition).

Alternative approaches were discussed on hotspot-dev@ojn:
  http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018562.html

The ClassLoaderData::_resolved_references weren't reported as roots, so YourKit reports many [Unreachable] Object[] arrays which are clearly arrays of strings from the resolved_reference array. The heapDumper was also not reporting the java.lang.Class init_locks as roots either so there were a number of [Unreachable] int[0] = {0} arrays. Lastly, the Universe saved backtrace instances for OOM weren't being reported so showed up as unreachable as well. Attached some pictures of making <resolved_references> and <init_lock> additional static fields of java.lang.Class, which technically they are but the heapdumper doesn't report instance fields of java.lang.Class, only statics of the Klass they represent. The other data that looks unreachable is many Object[2] arrays. These are the ClassLoaderData::_dependencies. I don't have a good way to represent them and we're looking into saving the dependencies in the ClassLoaderData::_handles blocks. There are few dependencies on non-delegating class loaders normally.

30-08-2017

I was looking at the heapDumper.cpp from jdk7 before the resolved_references array was introduced. The jdk7 equivalent of roots for the items in the resolved_references array were Strings (and other things) in the ConstantPool. But the JDK7 code doesn't walk the ConstantPool to report these items, in fact in HPROF_GC_CLASS_DUMP: // size of constant pool - ignored by HAT 1.1 writer->write_u2(0); I thought maybe dumping as a secret static field might be best, even though there may be RR that are orphaned by RedefineClasses (ie, they're found in the "old" constant pool caches).

28-08-2017

You can't move the resolved_references to the mirror because the redefinition puts the new constant pool and methods on the original InstanceKlass, and puts the old constant pool and methods on a scratch version of the class. Both old and new constant pools point to the original version of the InstanceKlass for (a lot) reasons. Since the original instanceKlass points to the mirror, the old and new resolved references array can't both be active at the same time for old methods to continue to run.

25-08-2017

Duplicate :	JDK-8173594 - jvmti heap dump reporting wrong object liveness info
Duplicate :	JDK-8199303 - Nashorn provides a memory leaks when using Tomcat and spark-java
Duplicate :	JDK-8197544 - Memory Leak when using Nashorn, missing gc roots
Relates :	JDK-8187896 - SA: ConstantPool::_resolved_references missing in heap dump by SA
Relates :	JDK-8173594 - jvmti heap dump reporting wrong object liveness info
Relates :	JDK-8080852 - Java heap dump doesn't contain klass mirror objects unless they are explicitly referenced
Relates :	JDK-8059340 - ConstantPool::_resolved_references is missing in heap dump