On Tue, 5 May 2026 19:41:17 GMT, Chris Plummer <[email protected]> wrote:

>> This PR implements two JVMTI enhancements: 
>> [8382702](https://bugs.openjdk.org/browse/JDK-8382702) and 
>> [8381063](https://bugs.openjdk.org/browse/JDK-8381063)
>> 
>> The update includes the following changes:
>>  - add spec clarifications for `VMObjectAlloc` and `SampledObjectAlloc` 
>> related to value object allocations
>>  - pass `nullptr` for `jobject` parameter of `VMObjectAlloc` and 
>> `SampledObjectAlloc` event callbacks
>>  - add test coverage with value object allocations for both event callbacks
>> 
>> Testing:
>>  - Test locally with newly added tests
>>  - Run 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).
>
> src/hotspot/share/prims/jvmti.xml line 14084:
> 
>> 14082:       <functionlink id="GetStackTrace"></functionlink>, a user can 
>> track which objects were allocated from which
>> 14083:       stack trace, and which are still live during the execution of 
>> the program.
>> 14084:       Note that value objects are not supported by weak references.
> 
> It seems that this comment is either unnecessary, or it should be expanded to 
> mention that the callback passes null for value objects. I know that is 
> already done below when describing the "object" parameter below, but it might 
> be worth mentioning here also.

Good suggestion, thanks. I'll also add wording for enabling preview release 
features.

> test/hotspot/jtreg/serviceability/jvmti/valhalla/VMObjectAllocValue/VMObjectAllocValueTest.java
>  line 48:
> 
>> 46:         MethodType mt = MethodType.methodType(void.class, String.class);
>> 47:         MethodHandle mh = 
>> publicLookup.findConstructor(VMObjectAllocValueTest.class, mt);
>> 48:         mh.invoke("str");
> 
> I assume the constructor is invoked in this way to make sure it isn't 
> flattened. You should add some comments to explain that.

There is no need in flattening. I've borrowed this part from another 
`VMObjectAlloc` test. My understanding is it is needed to trigger a JVMTI 
`VMObjectAlloc` event because NEW bytecode in Java code would not trigger it.

-------------

PR Review Comment: 
https://git.openjdk.org/valhalla/pull/2386#discussion_r3191820181
PR Review Comment: 
https://git.openjdk.org/valhalla/pull/2386#discussion_r3191810227

Reply via email to