RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
Serguei Spitsyn
sspitsyn at openjdk.org
Fri Jun 9 06:17:49 UTC 2023
On Thu, 8 Jun 2023 06:25:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> It was decided with Alan that it is okay to be in a waiting state. The `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` state requires a monitor to be blocked on, so it can be confusing. Alan's comment in the original PR [https://github.com/openjdk/jdk/pull/14298](https://github.com/openjdk/jdk/pull/14298) was:
>>> if the jt is carrying thread_oop and it's okay for the JVMTI state to reported as WAITING when waiting for something other than Object.wait.
>
> The mental model is that the carrier is blocked so this is what an observer using the APIs should see. My recollection is that JVMTI_THREAD_STATE_WAITING was okay because there is a wriggle room in the JVM TI spec, it only uses Object.wait as an example. There may be a few rough edges to smooth down in this area. It's okay to take time with this PR and expand the tests to cover more cases and get more confident that there aren't more issues.
We agreed with Alex to file a test RFE to improve test coverage in this area.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1223883294
More information about the hotspot-dev
mailing list