On Thu, 10 Sep 2026 19:38:48 GMT, Coleen Phillimore <[email protected]> wrote:
>> 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).
>
> Yes, hidden classes are not added to the system dictionary or added to
> ClassLoader.classes with addClass. This will call classes-do on only strong
> hidden classes. But I don't know if hidden classes are loaded with a
> non-null class loader today, so this is not a change in behavior. But I
> don't think they should be reported. An application can't look up these
> classes since they are not in the dictionary. I think they should stay
> hidden.
Lookup.defineHiddenClass is the API so it could be invoked on a Lookup where
the lookup class is defined to some other class loader. It called with the
STRONG class option then the hidden class would have a strong relationship the
defining class loader.
I see the update in the latest commit to skip hidden class and agree this keeps
existing behavior. One could argue that there is a long standing bug here in
that the heap walk doesn't report the reference to (strong) hidden classes. We
don't need to care about this here.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3988575364
