On Wed, 7 Jun 2023 11:48:19 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as >> "waiting" until the virtual thread unmounts. Right now, GetThreadState >> reports a state based the JavaThread status when it should return >> JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. >> The fix adds: >> - a special case for passive carrier threads >> - necessary test coverage to the existing JVMTI test: >> `serviceability/jvmti/vthread/ThreadStateTest`. >> >> Testing: >> - tested with the updated test: >> `serviceability/jvmti/vthread/ThreadStateTest` >> - submitted mach5 tiers 1-5 >> - TBD: to submit mach5 tier 6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: one function renaming Looks like this PR has caused regression failures in Tier1. We have between 2 and 5 failures per Tier1. See: [JDK-8309612](https://bugs.openjdk.org/browse/JDK-8309612) serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java#default fails after JDK-8307153 Because this failure is happening in Tier1, combined with the fact that we get much more JVM/TI testing in the upper Tiers, and tomorrow is the code-fork I'm proceeding with a [BACKOUT] and am testing that [BACKOUT] with an urgent Tier1 right now. See: [JDK-8309614](https://bugs.openjdk.org/browse/JDK-8309614) [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING ------------- PR Comment: https://git.openjdk.org/jdk/pull/14298#issuecomment-1580968712
