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. For JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT, the referrer is an array object so I don't think we can use it in the workaround. I think the best option from a bad lot is JVMTI_HEAP_REFERENCE_OTHER. Its description in the "Heap Reference Enumeration" table would need to be need to be updated. The description of the jvmtiHeapReferenceCallback's parameters would need to be updated too, specifically referrer_class_tag and referrer_tag_ptr will need to be updated. For referrer_tag_ptr it would need to specify that it points to the tag of the referrer object when the callback is for a reference rather than a heap root. Happy to help on wording the spec, CSR, and release note if you need it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5590625679
