On Thu, 17 Jul 2025 08:26:54 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:

> I've posted one concern on the spec updates. Otherwise, it looks okay to me. 
> I guess, a CSR will be filed for this update. I'm not sure what do you mean 
> by CR in the description. Do I understand this right that a potential JDWP 
> spec update we touched out of this PR will be considered separately?

I meant CSR. I'll fix that. JDWP will be updated by #26336.

> src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 406:
> 
>> 404:      *
>> 405:      * @throws OpaqueFrameException if target VM is unable to pop this 
>> frame
>> 406:      * (e.g. a virtual thread is not suspended at an event).
> 
> Nit: I'm not sure the comment at line 406 is fully correct. The 
> `IncompatibleThreadStateException` will be thrown if a virtual thread is not 
> suspended. So, the `OpaqueFrameException` will be thrown only when a virtual 
> thread is suspended but not at an event. The same concern should apply for 
> the line  488.

We are talking about the difference between "not suspended" vs "not suspended 
at an event". The former results in IncompatibleThreadStateException. For the 
latter I felt the wording implied it was suspended, but not at an event. Maybe 
it should just say "suspended, but not at an event"?

The JVMTI spec does not have this issue because it doesn't mention virtual 
threads as part of the OPAQUE_ERROR description. It instead mentions the method 
being native as an example of what can cause OPAQUE_ERROR. We can't do that 
here because a native method results in NativeMethodException, not 
OpaqueFrameException.

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

PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3084355508
PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2213550664

Reply via email to