RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
Daniel D. Daugherty
dcubed at openjdk.org
Wed Jun 7 14:44:10 UTC 2023
On Wed, 7 Jun 2023 11:48:19 GMT, Serguei Spitsyn <sspitsyn at 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
More information about the hotspot-dev
mailing list