JDK-7197269 : NPG: FollowReferences has no ClassLoader -> Class link to follow
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-09-10
  • Updated: 2017-02-11
  • Resolved: 2012-09-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 8 Other
8Fixed hs25Fixed
Related Reports
Duplicate :  
JDK-7195620 - NPG: Test VMMismatchException001 gets an java.lang.ArrayIndexOutOfBoundsException
Duplicate :  
JDK-7195619 - NPG: N-1 ClassLoaderReference.referringObjects() in permgen removal code
Duplicate :  
JDK-7169322 - Move list of java_lang_Class mirrors to back to the Java class loader object
Description
Before the permgen removal the classes defined by a class loader could be found in the ClassLoader.classes Vector.

After the the permgen removal this vector is not populated anymore. Instead the GC finds the classes through C++ objects outside the heap.

This change breaks tests and code relying on FollowReference to find java.lang.Class instances from a java.lang.ClassLoader instance.
I think 
nsk/jdi/ReferenceType/instances/instances004
also affected by this bug (or rather fixed by this fix).
Comments
EVALUATION Summary: restore java/lang/ClassLoader.addClass() upcall Reviewed-by: sspitsyn, dcubed, jmasa
17-09-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2a48c84f1d04
17-09-2012
EVALUATION I think we should add back the addClass call. The benefit of improved startup time wasn't realized and breaking compatibility is not worth this change. We will have redundant information that GC uses.
12-09-2012
EVALUATION The spec for JVM/TI FollowReferences is here: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#FollowReferences There are several key pieces to the description: > This function initiates a traversal over the objects that are > directly and indirectly reachable from the specified object or, > if initial_object is not specified, all objects reachable from > the heap roots. The heap root are the set of system classes, > JNI globals, references from thread stacks, and other objects > used as roots for the purposes of garbage collection. The above tells me that FollowReferences should do the same traversal over the objects that a garbage collection pass would do. And the following: > This function operates by traversing the reference graph. Before the Perm Gen Removal project, ClassLoader.classes provided a Java level reference from the class loader to the classes defined by the class loader. After the PGR project, the linkage from class loader to classes defined by the class loader is implemented by C++ code and data structures rather than a Java level reference. However, the garbage collector still traverses from the class loader to the classes defined by the class loader. It seems to me that JVM/TI FollowReferences needs to be updated to traverse from the class loader via the new C++ infrastructure to the classes defined by the class loader. One other point from the spec: > This function reports a Java programming language view of object > references, not a virtual machine implementation view. Since the new linkage from class loader to classes defined by the class loader is now implemented by C++ code and data structures, it seems to me that FollowReferences() should not try and report the internal C++ data structure. I'm specifically saying here that we don't need to add a new jvmtiHeapReferenceKind. In the pre-PGR code base, I think the classes defined by a class loader are reported as JVMTI_HEAP_REFERENCE_FIELD and I would do the same in the PGR code base to preserve compatibility.
12-09-2012