RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v3]

Alex Menkov amenkov at openjdk.org
Tue Jul 8 18:47:39 UTC 2025


On Tue, 8 Jul 2025 01:52:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm also unclear if this code in the handshake is sufficient for dealing with the case where we have a mounted virtual thread initially, but it is unmounted before the handshake gets to execute:
> 
> ```
>     if (java_lang_VirtualThread::is_instance(_java_thread())) {
>         // if (thread->vthread() != _java_thread()) // We might be inside a System.executeOnCarrierThread
>         const ContinuationEntry* ce = thread->vthread_continuation();
>         if (ce == nullptr || ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())) {
>           return; // not mounted
>         }
>       }
> ```
> 
> The commented line seems an inaccurate characterization as we could be executing a completely different virtual thread on this carrier now - which is not related to `executeOnCarrierThread`.

I suppose the comment is obsolete. I don't see `executeOnCarrierThread` in the current codebase.
The condition checks if there were some changes in vthread/carrier:
`ce == nullptr` - the carries has no mounted vthread now (i.e. the vthread has been unmounted);
`ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())` - the carrier has other vthread mounted;
Even if there were unmount/mount the same vthread on the carrier, it's fine (we need vthread stack trace and we are in handshake with its carrier)

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3049959218


More information about the hotspot-dev mailing list