Re-analysed this.
A thread in native must have always have a walkable java stack, if a java stack exists.
JFR sampler thread should not need to make the stack walkable when the thread is in native.
The underlying issue is that in some native transition we don't check jfr trace-suspend.
I could reproduce somewhat reliable with:

        try {
            @SuppressWarnings("unused")
            int[] array = new int[-3];
        } catch (NegativeArraySizeException e) {
            continue;
        }

Looping in hundreds of thread and changes to the sampler so it was running like crazy.

 assert(_last_Java_pc == NULL) failed: already walkable

Stack: [0x00007fb5b5750000,0x00007fb5b5850000], sp=0x00007fb5b584d4b0, free space=1013k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xc2ae1a] frame::sender_for_entry_frame(RegisterMap*) const+0x1da
V [libjvm.so+0xc2c208] frame::sender(RegisterMap*) const+0x2a8
V [libjvm.so+0xf2e5f8] JfrStackTrace::record_thread(JavaThread&, frame&)+0x378
V [libjvm.so+0xf52097] JfrNativeSamplerCallback::call()+0xf7
V [libjvm.so+0xf55dff] JfrThreadSampleClosure::sample_thread_in_native(JavaThread*, JfrStackFrame*, unsigned int)+0xdf
V [libjvm.so+0xf5602c] JfrThreadSampleClosure::do_sample_thread(JavaThread*, JfrStackFrame*, unsigned int, JfrSampleType)+0x14c
V [libjvm.so+0xf582f1] JfrThreadSampler::task_stacktrace(JfrSampleType, JavaThread**) [clone .constprop.58]+0x3f1
V [libjvm.so+0xf58a26] JfrThreadSampler::run()+0x196
V [libjvm.so+0x17bc800] Thread::call_run()+0x100
V [libjvm.so+0x14a253d] thread_native_entry(Thread*)+0x10d