On Thu, 3 Sep 2026 22:15:25 GMT, Coleen Phillimore <[email protected]> wrote:
>> 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). > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > hack mirrors into class loader for referring class loader We're in an odd state here - we don't want to waste the heap space, and deal with the complications, for the on-heap Arraylist given we already have all this info stored in the ClassLoaderData. Getting rid of this ArrayList is a good change. The issue is we still want to report a reference from the ClassLoader -> classes that works with the current JVMTI spec. Here are our options: * Use `JVMTI_HEAP_REFERENCE_FIELD` with a dummy index of -1. The index field of the `jvmtiHeapReferenceInfoField` is a `jint` so a negative value is clearly a synthetic field. * Create a Class[] on the j.l.Class and use `JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT`. We will still have to generate a nonsensical index for that array. * Use `JVMTI_HEAP_REFERENCE_OTHER` which is unfortunately described as a root: "Heap root reference: other heap root reference." 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5545266705
