On Wed, 9 Sep 2026 02:26:20 GMT, Serguei Spitsyn <[email protected]> wrote:
>>> The same should apply to the JVMTI [Follow >>> References](https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#FollowReferences). >>> It has to report the references from ClassLoader to its loaded classes. It >>> is better to report the same way as it was before. The removed >>> ClassLoader.classes is just an implementation detail. It was used because >>> it was convenient to use. >> >> This contradicts the FollowReferences spec which explicitly says "This >> function reports a Java programming language view of object references, not >> a virtual machine implementation view." If there is no Java programming >> language reference (ie: Classloader.classes is removed), then we should not >> report such references. >> >>> The removed ClassLoader.classes is just an implementation detail. >> >> Exactly. If there was an expectation for a Classloader->Class mapping, then >> why isn't there an appropriate `JVMTI_HEAP_REFERENCE_XXXXX` type that we can >> use here? >> >> If we're going to require a synthetic connection, then we should create a >> new `JVMTI_HEAP_REFERENCE_CLASS_LOADER_CLASS` type to manage the >> Classloader->Class mapping. Otherwise, we're just specing our implementation > >> Exactly. If there was an expectation for a Classloader->Class mapping, then >> why isn't there an appropriate >> JVMTI_HEAP_REFERENCE_XXXXX type that we can use here? >> >> If we're going to require a synthetic connection, then we should create a >> new >> JVMTI_HEAP_REFERENCE_CLASS_LOADER_CLASS type to manage the >> Classloader->Class mapping. >> Otherwise, we're just specing our implementation > > I agree, it would probably better to have a special ref kind for this. But I > guess it did not look that import to introduce new ref kind just for this > purpose. The `JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT` was good enough at the > moment. But now we probably have a reason to introduce new ref kind. I'm not > very sure about it yet. > @sspitsyn The JVMTI GetLoadedClasses doesn't use the classes vector, it walks > the ClassLoaderData, and GetClassLoaderLoadedClasses walks the dictionary > inside the ClassLoaderData. It is exactly what I wanted to say. We have API's which already use loaded classes from the `ClassLoaderData`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5605679816
