RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v4]
Serguei Spitsyn
sspitsyn at openjdk.org
Wed Jul 16 03:35:48 UTC 2025
On Fri, 11 Jul 2025 05:06:41 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Except I'm now discovering that can't work other than to abandon the virtual thread in question if you found the carrier has changed, otherwise you are in a handshake with the wrong carrier and so can't grab the stack - but that means you need to retry for this virtual thread.
>
> I see the current code just produces an empty stack trace if the virtual thread is found to have switched carriers. This seems wrong. We should be "pinning" the virtual thread whilst we try to get its stacktrace, such that it is unmounted or else mounted and fixed to a carrier. Other thread walking code uses the JvmtiVTMSTransitionDisabler to try and achieve this.
Sorry for being late to the party. I still need to walk through all the comments but it seems you have already caught the main problem with virtual threads. Nothing protects them from being concurrently mounted/unmounted/remounted. It is why the `JvmtiVTMSTransitionDisabler` is used in the JVMTI code. But, please, note that the `JvmtiVTMSTransitionDisabler` mechanism is enabled only when there is a JVMTI agent. Otherwise, it has been disabled for scalability purposes to exclude potentially high performance overhead at the VTMS transition points.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2209135122
More information about the hotspot-dev
mailing list