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. I'll suggest again based on the existing JVMTI specs that we should NOT be generating synthetic references here. I know I suggested earlier we should, but having looked further into this, I was wrong. JVMTI's FollowReferences says: > This function reports a Java programming language view of object references, > not a virtual machine implementation view. The following object references > are reported when they are non-null: > * Instance objects report references to each non-primitive instance fields > (including inherited fields). > * Instance objects report a reference to the object type (class). > * Classes report a reference to the superclass and directly > implemented/extended interfaces. > * Classes report a reference to the class loader, protection domain, signers, > and resolved entries in the constant pool. > * Classes report a reference to each directly declared non-primitive static > field. > * Arrays report a reference to the array type (class) and each array element. > * Primitive arrays report a reference to the array type. Given that this PR is changing the Java programming view of object references by removing a reference field (the ArrayList), it seems very strange for us to synthetically insert it back. Users who wish to iterate through the Classloaders's classes should collect the set of Classloaders visited during the initial heap traversal and then use `GetClassLoaderClasses` to traverse from each class. JVMTI agents are free to benefit from existing references (like the ArrayList) but cannot rely on undocumented edges remaining present when the implementation doesn't need them anymore. This change is no different than other internal implementation details changing (ie: Jigsaw changing the built-in classloaders to no longer be URLClassLoaders). It's just unfortunate that we have a test that was coded too tightly to the previous implementation ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5591349621
