On Tue, 8 Sep 2026 15:07:10 GMT, Coleen Phillimore <[email protected]> wrote:
>> Remove the upcall to addClass during class loading. The comment says it's >> only so GC can keep classes alive while the class loader is alive. We have >> other ways to do that. There were some JVMTI tests in the past that failed >> without this vector but today seems to be only one test. Maybe there's some >> code that has a dependency on this in heap walking. >> Tested tier1-6 >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Coleen Phillimore has updated the pull request incrementally with two > additional commits since the last revision: > > - fix copyright > - This is why I picked JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT. It's what it > used to return. Sorry for being late to this discussion. In fact, I need to read carefully what was already discussed here and can easily miss something important. So, please, fix me if needed. First point is to check on how to treat this `FollowReferences` spec statement: > This function reports a Java programming language view of object references, > not a virtual machine implementation view. The Java programming language view does not include directly anything like the JVM `ClassLoaderData` which has references to the classes loaded by a specific `ClassLoader`. However, the list of classes loaded by a specific loader virtually and logically exists and and can be accessed via some API's, e.g. : - JVMTI [`GetClassLoaderClasses`](https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetClassLoaderClasses): Returns an array of all classes which this class loader can find by name via [ClassLoader::loadClass](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)), [Class::forName](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)) and bytecode linkage. That is, all classes for which initiating_loader has been recorded as an initiating loader. - Instrumentation.[getInitiatedClasses](https://docs.oracle.com/en/java/javase/25/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#getInitiatedClasses(java.lang.ClassLoader)): Returns an array of all classes which loader can find by name via [ClassLoader::loadClass](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)), [Class::forName](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Class.html#forName(java.lang.String)) and bytecode linkage. That is, all classes for which loader has been recorded as an initiating loader. If the supplied loader is null, classes that the bootstrap class loader can find by name are returned. 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 vector of class in the `ClassLoader` is just an implementation detail. It was used just because it was convenient to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5593095959
