In the loom repository I'm experimenting with stricter checks in the Access API to find places where we access oops while in the native or blocked state. Accessing oops in those states are dangerous, because a safepoint can be started and run simultaneously. Some code safeguards this by holding the thread lock, but in places were we don't we need to take a closer look and fix this.

This bug is one that seems to be existing in the upstream repository:

char* java_lang_String::as_platform_dependent_str(Handle java_string, TRAPS) {
  typedef char* (*to_platform_string_fn_t)(JNIEnv*, jstring, bool*);
  static to_platform_string_fn_t _to_platform_string_fn = NULL;

  if (_to_platform_string_fn == NULL) {
    void *lib_handle = os::native_java_library();
    _to_platform_string_fn = CAST_TO_FN_PTR(to_platform_string_fn_t, os::dll_lookup(lib_handle, "GetStringPlatformChars"));
    if (_to_platform_string_fn == NULL) {
      fatal("GetStringPlatformChars missing");
    }
  }

  char *native_platform_string;
  { JavaThread* thread = THREAD;
    jstring js = (jstring) JNIHandles::make_local(thread, java_string());
    bool is_copy;
    HandleMark hm(thread);
    ThreadToNativeFromVM ttn(thread);
    JNIEnv *env = thread->jni_environment();
    native_platform_string = (_to_platform_string_fn)(env, js, &is_copy);
    assert(is_copy == JNI_TRUE, "is_copy value changed");
    JNIHandles::destroy_local(js);
  }
  return native_platform_string;
}

The JNIHandles::destroy_local function calls NativeAccess<>::oop_store(jobject_ptr(handle), (oop)NULL), while inside the scope that has put the thread in the native state. It should probably be moved outside the ThreadToNativeFromVM scope.

This was found with extra verification code in the Access API, while running com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java.