On Tue, 28 Apr 2026 02:02:38 GMT, Serguei Spitsyn <[email protected]> wrote:
>> This enhancement is to a add JVMTI debugging support for value object >> construction. >> The fix includes: >> - Minor `GetLocalObject` and `GetLocalInstance` spec clarifications >> - JVMTI functions `GetLocalObject` and `GetLocalInstance` now return a >> snapshot of the `THIS` object if it is requested during a value object >> construction. >> - This update adds new test with a needed test coverage: >> `test/hotspot/jtreg/serviceability/jvmti/valhalla/GetCtorLocal`. >> - Some corrections in the test >> `test/hotspot/jtreg/serviceability/jvmti/valhalla/GetSetLocal` for >> unification with the test above. >> >> Testing: >> - Tested locally with new test `GetCtorLocal` >> - Tested with mach5 tiers 1-6 >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: comments updates for two tests src/hotspot/share/prims/jvmtiImpl.cpp line 500: > 498: BufferedValuePayload dst(obj_copy, klass); > 499: src.copy_to(dst); > 500: } When you combine the semantics of klass->allocate_instance() and copying with BufferedValuePayload, are you guaranteed to have a fully initialized object? Also, does BufferedValuePayload do deep cloning, and if yes, is that necessary? I think it would be good to have someone from the GC team to look at this specific code to make sure there are no GC concerns with what you are doing. test/hotspot/jtreg/serviceability/jvmti/valhalla/GetCtorLocal/libValueGetCtorLocal.cpp line 80: > 78: } else { > 79: // cached_this must be a snapshot that idoes not mutate > 80: // when the ctor changes field values Suggestion: // cached_this must be a snapshot that does not mutate // when the ctor changes field values test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 400: > 398: // No other references. > 399: // ObjectID is generated at the 1st breakpoint (reference to > a snapshot of heap object being constructed), > 400: // and later we get snapshots of the updated oop as it's > content is changing. Suggestion: // and later we get snapshots of the updated oop as its content is changing. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2363#discussion_r3157149778 PR Review Comment: https://git.openjdk.org/valhalla/pull/2363#discussion_r3156912347 PR Review Comment: https://git.openjdk.org/valhalla/pull/2363#discussion_r3156942604
