On Wed, 9 Sep 2026 17:35:53 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: > > Fix wording in test. Not a special root reference. src/hotspot/share/prims/jvmtiTagMap.cpp line 3133: > 3131: > 3132: for (int i = 0; i < klasses->length(); i++) { > 3133: Klass* k = klasses->at(i); By default, hidden classes don't have a strong relationship with their class loader so there is no upcall to ClassLoader.addClass. I'm hazy on the details as to how ClassLoaderData handles non-strong vs. strong hidden classes so wondering if ClassLoaderData.classes_do will invoke the closure for all, none or just strong hidden classes. It looks like it will invoke it for strong hidden classes, which is okay, but may be a subtle behavior change (a change for the good of course). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3977555153
