On Tue, 8 Sep 2026 15:07:10 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 two > additional commits since the last revision: > > - fix copyright > - This is why I picked JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT. It's what it > used to return. For discussion sake, I needed to add a new ref kind JVMTI_REFERENCE_OTHER. I was going to update the description of JVMTI_HEAP_REFERENCE_OTHER but it's already sufficiently vague: <constant id="JVMTI_HEAP_REFERENCE_OTHER" num="27"> Heap root reference: other heap root reference. </constant> @sspitsyn The JVMTI GetLoadedClasses doesn't use the classes vector, it walks the ClassLoaderData, and GetClassLoaderLoadedClasses walks the dictionary inside the ClassLoaderData. So the compatibility issue with this would be an agent doing a switch statement on JVMTI type for a class when starting from the java.lang.ClassLoader (?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5601566592
