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. > There is *nothing* in the spec that mentions that we can get classes from the > class loader, It is an implicit expectation given that a ClassLoader is basically something that maintains a set of classes that it defined. And the implementation supported this through the classes vector. So expectation and reality have matched for over 20 years. That is not something you can just throw out. > 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. As Coleen noted earlier this is not functionally the same. `GetClassLoaderClasses` returns all the classes for which the loader is an initiating loader, not just those for which it is the defining loader. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5592856695
