The s.m.Unsafe representation in hotspot and method registration (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Mon Mar 24 16:42:50 UTC 2014

I started working on a patch to remove the monitor related methods on Unsafe, and was thinking this is gonna be easy, it kind of is, but there is some curious code for the registration of the native methods:

http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/unsafe.cpp#l1685

JVM_ENTRY(void, JVM_RegisterUnsafeMethods(JNIEnv *env, jclass unsafecls)) UnsafeWrapper("JVM_RegisterUnsafeMethods"); { ThreadToNativeFromVM ttnfv(thread);

// Unsafe methods
{
  bool success = false;
  // We need to register the 1.6 methods first because the 1.8 methods would register fine on 1.7 and 1.6
  if (!success) {
    success = register_natives("1.6 methods",   env, unsafecls, methods_16,  sizeof(methods_16)/sizeof(JNINativeMethod));
  }
  if (!success) {
    success = register_natives("1.8 methods",   env, unsafecls, methods_18,  sizeof(methods_18)/sizeof(JNINativeMethod));
  }
  if (!success) {
    success = register_natives("1.5 methods",   env, unsafecls, methods_15,  sizeof(methods_15)/sizeof(JNINativeMethod));
  }
  if (!success) {
    success = register_natives("1.4.1 methods", env, unsafecls, methods_141, sizeof(methods_141)/sizeof(JNINativeMethod));
  }
  if (!success) {
    success = register_natives("1.4.0 methods", env, unsafecls, methods_140, sizeof(methods_140)/sizeof(JNINativeMethod));
  }
  guarantee(success, "register unsafe natives");
}

And there are multiple declarations of the same methods in various arrays. What is the rational for this kind of registration?

I presume when removing methods one removes entries from all arrays?

--

One a separate note i think we can also remove all methods marked with @Deprecated (which according to the comments were done so in 1.4.1).

Paul.

More information about the core-libs-dev mailing list