Hi Paul, I would guess this is because of the HSX model where we could use the same VM with different majors of the JDK. Would that make sense?
cheers /Joel On 24 Mar 2014, at 17:42, Paul Sandoz <paul.san...@oracle.com> wrote: > 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. > > >
