RFR: 8373485: JFR Crash during sampling: assert(jt->has_last_Java_frame()) failed: invariant
Aleksey Shipilev
shade at openjdk.org
Mon Jan 12 09:46:40 UTC 2026
On Sun, 11 Jan 2026 12:39:06 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
> Greetings,
>
> When sampling threads in state _thread_in_native, there is a missing memory barrier when UseSystemMemoryBarrier is used, because it must be emitted manually.
>
> Testing: jdk_jfr
>
> Thanks
> Markus
>
> PS "threads_lock" local variable was renamed to "lock" not to confuse with the global Threads_lock.
Man, this is confusing. Looks to me thread states are guarded specially. Looking at `Handshake::execute`, I see the pattern is:
// Separate the arming of the poll in add_operation() above from
// the read of JavaThread state in the try_process() call below.
if (UseSystemMemoryBarrier) {
SystemMemoryBarrier::emit();
} else {
OrderAccess::fence();
}
This follows `HandshakeState::add_operation` -> `SafepointMechanism::arm_local_poll_release`. `arm_local_poll_release` is what `JfrSampleThread::sample_native_thread` also does. So, the fix should follow what `Handshake` does. I think you are trying to do the same, but piggy-back on `OA::fence()` already done in `JfrMutexTryLock` when `-UseSystemMemoryBarrier`?
-------------
PR Review: https://git.openjdk.org/jdk/pull/29155#pullrequestreview-3649901629
More information about the hotspot-jfr-dev
mailing list