There exist two service threads in the JFR framework that perform operations inside the VM. They are JavaThreads running in thread state "_thread_in_vm".

The JFR Recorder Thread no longer executes Java code, but participates in notify() for communication with other threads running in Java. With Event Streaming, this thread now runs much more frequently, mainly tasked with flushing memory contents to disk at a regular intervals.

The JFR Periodic Task Thread runs a subset of registered periodic tasks implemented in the VM. For example, it reads performance counters exposed by the operating system.

There is no reason safepoint synchronizations should need to wait for these threads to reach a safepoint poll in the VM and therefore we should attempt to exclude them from the safepoint protocol where possible.

For the JFR Periodic Task thread, since it originates from and also executes Java code ("_thread_in_Java"), the solution would be to switch it to "_thread_in_native" where possible inside the VM. It must still transition to "_thread_in_vm" for some parts, for example when submitting a safepoint operation.

The JFR Recorder Thread could possibly be changed from a JavaThread to a NamedThread, but depends on having a working notification mechanism with other Java threads. If an alternative to this is not possible, it should be fine to keep it as a JavaThread, letting it spend most of its lifetime as "_thread_in_native", performing transitions only for specific operations.