As noted in the comments of JDK-8369515, when a thread is executing in native code it is presumed safepoint-safe as it cannot interfere with anything on the Java heap. However, if the thread has gained access to the raw array of a Java String or array instance via the JNI "critical" access methods, this is no longer true, as it can manipulate that array concurrently with code executing within the VM. In particular, the thread can be suspended through JVM TI and the debugger can then interact with the object assuming it is safe to do so, when in fact it is not.

We can remedy this problem by using the suspension deferral mechanism that was put in place for virtual threads, and disable suspension while "critical" access is in progress. It remains incumbent on the code using the critical API's to make the critical section as short as possible so that suspension is not delayed for too long.