On Thu, 10 Sep 2026 09:04:06 GMT, Alan Bateman <[email protected]> wrote:
>> 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 2472:
>
>> 2470: inline bool CallbackInvoker::report_other_reference(const
>> JvmtiHeapwalkObject& referrer, const JvmtiHeapwalkObject& referree) {
>> 2471: if (is_basic_heap_walk()) {
>> 2472: return
>> invoke_basic_object_reference_callback(JVMTI_REFERENCE_OTHER, referrer,
>> referree, -1);
>
> Just to double check, is_basic_heap_walk is true for the legacy/deprecated
> "Heap 1.0" functions, is that right? In that case, this looks like it will
> invoke the callback specified to IterateOverObjectsReachableFromObject with a
> value that is not defined by jvmtiObjectReferenceKind (the newer API uses the
> enum jvmtiHeapReferenceKind, the deprecated API uses the older enum
> jvmtiObjectReferenceKind).
>
> From a stewardship perspective, I think it defendable to "degrade
> "IterateOverObjectsReachableFromObject and not synthesize refs from a class
> loader to the classes that it has defined. FollowReferencewas the replacement
> for this function JDK 6. The so-called "Heap 1.0" functions have been
> deprecated since JDK 17 ([CSR](https://bugs.openjdk.org/browse/JDK-8268242)).
Okay, this sounds good. I will also adjust this CSR.
> 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.
> src/hotspot/share/prims/jvmtiTagMap.cpp line 3137:
>
>> 3135: // Pretend the classes are referred indirectly by the class
>> loader. They are
>> 3136: // root objects, so make them other references.
>> 3137: if (!CallbackInvoker::report_other_reference(o, m)) {
>
> The comment "They are root objects", do you mean they will be reported as
> roots (no referrer) too?
These will not be reported as ROOT objects for this. I use "ROOT" to refer to
being referenced by metadata. The classes in the null class loader are
reported as JVMTI_HEAP_ROOT_SYSTEM_CLASS.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3982777299
PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3982815638
PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3982882563
