On Wed, 16 Sep 2026 01:15:05 GMT, David Holmes <[email protected]> wrote:
>> [Picking up and finishing off https://github.com/openjdk/jdk/pull/32519 for >> Coleen] >> >> 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). > > test/hotspot/jtreg/serviceability/HeapDump/ClassLoaderFieldsTest.java line 50: > >> 48: * @summary Verifies heap dump contains a reference to a java.lang.Class >> instance from its ClassLoader >> 49: * @library /test/lib >> 50: * @run driver ClassLoaderFieldsTest > > I don't quite understand the name of the test - what "fields" are we > referring to? The name isn't great but I'm not sure what else to call it. The test is asserting that the class is present in the heap dump even though the "classes" field has been removed: JavaClass classLoaderClass = snapshot.findClass("java.lang.ClassLoader"); boolean hasClasses = Arrays.stream(classLoaderClass.getFields()) .anyMatch(field -> field.getName().equals("classes")); Asserts.assertFalse(hasClasses); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32890#discussion_r4030291408
