On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <[email protected]> wrote:
>> JDK-8364343 upgraded the virtual thread transition management to be
>> independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace
>> to use it and remove the suspend + retry code from Thread.getStackTrace.
>>
>> A summary of the changes:
>>
>> - java_lang_Thread::async_get_stack_trace is changed to use the new
>> handshake op so it can be called to get the stack trace of a started thread
>> in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not
>> compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to
>> StackTraceElement to complete the init of the stack trace
>>
>> The changes mean that Thread::getStackTrace may be slower when sampling a
>> virtual thread in transition. This case should be rare, and it isn't really
>> a performance critical op anyway. I prototyped use a spin loop and an
>> increasing wait time in MountUnmountDisabler::disable_transition_for_one to
>> avoid the wait(10) but decided to leave it out for now. Future work may
>> examine this issue as there may be other cases (with JVMTI) that would
>> benefit from avoiding the wait.
>>
>> A future PR might propose to change Thread.getStackTrace to use
>> ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed.
>> This requires more extensive changes to ThreadSnapshotFactory to reduce
>> overhead when only the stack trace is required.
>>
>> Testing: tier1-5. The changes has been already been tested in the loom repo
>> for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains seven additional
> commits since the last revision:
>
> - Merge branch 'master' into JDK-8376568
> - Merge branch 'master' into JDK-8376568
> - Review feedback
> - Improve asserts
> - Cleanup
> - Merge branch 'master' into Thread.getStackTrace
> - Initial commit
src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 63:
> 61: */
> 62: static ThreadSnapshot of(Thread thread) {
> 63: ThreadSnapshot snapshot = thread.isAlive() ? create(thread) :
> null;
Looking at the implementation of `Thread.isAlive` for platform threads I'm
confused now. It checks `eetop != 0`, but we set it
[here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/javaThread.cpp#L1732),
before we change the state to RUNNABLE
[here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/thread.cpp#L408).
So I'm wondering if we could hit the assert added in the last update in
`ThreadSnapshotFactory::get_thread_snapshot`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2766377403
