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