On Thu, 3 Sep 2026 22:15:25 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 one > additional commit since the last revision: > > hack mirrors into class loader for referring class loader Another option here is to simply drop the reference from the classloader->class as a consequence of removing the ArrayList. There's nothing in the spec that requires us to generate "good will" references for internal connections that don't mirror the heap based view of those connections. Just like with other internals changes, we don't need preserve references that don't exist anymore. Users who need the Classloader->class references are free to use `GetClassLoaderClasses` if they want those references. Given there is no specified reason to generate the references, maybe we should stop generating them when we remove the ArrayList (users' shouldn't depend on internals) and let users use the existing JVMTI functions to get the mapping if they need it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5586624824
