On Wed, 28 Jan 2026 20:54:35 GMT, Patricio Chilano Mateo 
<[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.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1944:
> 
>> 1942: 
>> 1943:       bool is_virtual = 
>> java_lang_VirtualThread::is_instance(_thread_h());
>> 1944:       bool vthread_carrier = !is_virtual && (java_thread != nullptr) 
>> && (java_thread->vthread_continuation() != nullptr);
> 
> The extra `java_thread != nullptr` should not be necessary.

What would force it to be non-null? (Related: under what conditions will `th` 
be null and what does that imply about the value of `_thread_h()`?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739888377

Reply via email to