On Tue, 19 Dec 2023 05:16:38 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Good point. I'll remove dependency on JVMTI. >> I don't think approximation would be good here (comparing state to >> RUNNABLE/PINNED/TIMED_PINNED or comparing carrierThread with null). >> It's racy and we have a chance to not dump unmounted vthread or dump mounted >> vthread twice. >> Maybe `is_vthread_mounted` should check if the virtual thread continuation >> has non-empty chunk. > > If that is racy then any solution is going to be racy. I assumed this was all > happening at a global safepoint, otherwise threads could be > mounting/unmounting at any time. > > I said "approximation" only because I'm unsure exactly when the thread state > gets updated in the mounting/unmounting process. I mean race between virtual thread state change and the thread stack switch (to/from carrier). Correct condition here is "dump the virtual thread if it was not dumped as mounted virtual thread". Most likely for RUNNABLE/PINNED/TIMED_PINNED we can be sure the thread is mounted, but we can get vthread in transition (PARKING, YIELDING, etc). Virtual threads may be in transition at safepoints (but they can't change mounted/unmounted state). So I think `is_vthread_mounted` can be implemented in 2 ways: 1) copy logic of JvmtiEnvBase::get_JavaThread_or_null: get JavaThread for java_lang_VirtualThread::carrier_thread(vt); if not null, check Continuation::is_continuation_mounted(java_thread, java_lang_VirtualThread::continuation(vt)) - this is to handle transition, when vthread is already unmounted, but carrierThread is not yet set to null; 2) check that java_lang_VirtualThread::continuation(vt) doesn't have non-empty chunk. AFAIU this is true for mounted vthreads. If we get it for unmounted vt, its stack trace of the thread is empty anyway, so it's ok to skip it (most likely it can happen only if thread state is NEW or TERMINATED, we already skip such vthreads). @AlanBateman could you please comment if my understanding is correct ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17134#discussion_r1431959463
