On Fri, 3 Jul 2026 15:54:34 GMT, Alan Bateman <[email protected]> wrote:

> JVMTI GetLocalObject/GetLocalInstance: Right now, the behavior when preview 
> features is enabled is buried in the description of the value_ptr parameter. 
> Add text to the function descriptions so that it is more discoverable.
> 
> JDWP: I realize there has been some flip-flop on this but I think we need the 
> "When preview features are enabled" text and remove any possibility of 
> developers not understanding that the feature is in preview.
> 
> JDI: The first use of "value object" or "value class" in the updated methods 
> now link to Class::isValue. This will ensure that the "PREVIEW" superscript 
> appears in the usage. It might be that we come up with a better way to 
> communicate that the behavior is for value objects which are in preview for 
> this release.
> 
> JDI StackFrame.getValue/getValues: JDI has always filtered out "this" from 
> the local variables so I think the only way for JDI tools to get a local 
> variable for an object under construction is if the constructor invokes a 
> method with "this" as a parameter (this-escape). Instance fields in value 
> objects are strictly-initialized final fields so any leaking of "this" will 
> be after the object has been initialized. I think we can drop the text added 
> to these two methods. If this get a "this" for a value object under 
> construction then it will already be initialized, and setValue will fail as 
> the fields are final. We need to keep the text in StackFrame.thisObject, 
> which is tweaked slightly to make it a bit clearer. Future work might be 
> needed here to have ObjectReference.getValue fail if the field has not been 
> initialized.
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 460:

> 458:      * a {@linkplain Class#isValue() value class}. Forcing early return
> 459:      * on a thread with only one frame on the stack causes the thread to
> 460:      * exit when resumed.

Do you want this update in the JDWP spec also?

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

PR Review Comment: 
https://git.openjdk.org/valhalla/pull/2627#discussion_r3521318154

Reply via email to