On Wed, 16 Sep 2026 20:08:53 GMT, Dan Heidinga <[email protected]> wrote:
>> src/hotspot/share/classfile/loaderConstraints.cpp line 448:
>>
>>> 446: // so we don't have a dangling pointer to InstanceKlass in the
>>> LoaderConstraintTable.
>>> 447: void LoaderConstraintTable::check_failed_loaded_klass(InstanceKlass*
>>> klass,
>>> 448: ClassLoaderData*
>>> loader) {
>>
>> Not sure this really carries its weight any more as it doesn't actually need
>> to do anything. Based on the comments once we have added to the constraint
>> table it should not be possible for there to be any exceptions that would
>> require it to be removed again.
>
> I'd like to keep it as an assert that the case we don't believe can happen
> hasn't happened. Can we remove it in a future RFE?
Sure. I think the exception possibility in this code is a bit confusing anyway.
>> 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);
`ClassLoaderDefinedClassesTest` ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32890#discussion_r4032069398
PR Review Comment: https://git.openjdk.org/jdk/pull/32890#discussion_r4032053671
