On Fri, 4 Sep 2026 19:07:35 GMT, Dan Heidinga <[email protected]> wrote:
> None of these options is a great fit. My suggestion, in order of preference, > would be to do: > > 1. Use `JVMTI_HEAP_REFERENCE_OTHER` as the closest approximation of a > synthetic reference from the classloader->class > 2. Use `JVMTI_HEAP_REFERENCE_FIELD` and an index of -1 to indicate a > synthetic reference, similar to how -1 is used in other places to, like the > jvmtiHeapReferenceCallback "length" parameter to indicate no data. > > Neither of these is a perfect fit but they keep the connection between > classloader->class and don't perturb the spec. It's worth exploring both but they both would require spec changes. We touched on some of this in previous comments when spitballing things to try. I think the summary is: 1. JVMTI_HEAP_REFERENCE_OTHER is specified for root objects. It specifies that referrer_tag_ptr is null. To be useful for a class loader -> class reference would require that it be non-null so that the callback can read (or set) the referrer's tag value. A callback handling this ref kind is probably ignoring referrer_tag_ptr (and referrer_class_tag). It's hard to gauge the compatibility impact, it may be that some heap walking agents will just treat the class object as a root object. Updating the agent, to distinguish a root object from a reference, would require the agent checking if referrer_tag_ptr is null or non-null. 2. JVMTI_HEAP_REFERENCE_FIELD uses a ref info of jvmtiHeapReferenceInfoField so that the callback has the field index. The index is specified to be the index of the fields returned by GetClassFields. A worry with having the index be -1 is that the callback might crash or misbehave so I suspect this direction has more compatibility risk than the first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5550261800
