On Fri, 28 Aug 2026 12:19:23 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 comments. src/hotspot/share/classfile/loaderConstraints.cpp line 447: > 445: // Removes a class that was added to the table then class loading > subsequently failed for this class, > 446: // so we don't have a dangling pointer to InstanceKlass in the > LoaderConstraintTable. > 447: void LoaderConstraintTable::remove_failed_loaded_klass(InstanceKlass* > klass, If we remove ClassLoader.addClass() and the potential OOM, then I don't think we need this method at all. As a temporary step, we could change this to be an assert that ensures `p->klass() != klass` to build confidence that this function is unnecessary and remove it in a later cleanup ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3881520314
