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. I think artificially preserving the old behavior should be enough. I don't see what the problem with this is. I don't know how to document this and don't believe you that there will be any customer who does not erroneously has explicitly encoded some dependence on the 'classes' field would be experience this difference. We could put something in the release notes but I'm again not sure how to word it nicely. There is *nothing* in the spec that mentions that we can get classes from the class loader, and what the reference kind of this referred object would be. This is a tiny piece of the greater heap features which I agree we need to understand how to deprecate these old invasive features. But that's a bigger project requiring a lot more information than this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5590359135
