RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state

[Patricio Chilano Mateo]

On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

I think `JvmtiExport::has_frame_pops` should just check if `thread->jvmti_thread_state()` is nullptr and return false, and not try to create the state. Same with `JvmtiExport::continuation_yield_cleanup()`. This `JvmtiExport::get_jvmti_thread_state()` method was added in 8312174 but I don’t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the `JvmtiThreadState` created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in `VTMS_unmount_begin` so we would leave the wrong state in the platform thread until the next transition.

@sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn’t we have a `!cont.entry()->is_virtual_thread()` check too?

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3386916577