Bug: https://bugs.openjdk.java.net/browse/JDK-8249650
webrev: http://cr.openjdk.java.net/~dholmes/8249650/webrev/
This is a simple cleanup that touches files across a number of VM areas
- hence the cross-post.
Whilst working on a different JNI fix I noticed that in most cases in
jni.cpp we were using the following form of make_local:
JNIHandles::make_local(env, obj);
and what that form does is first extract the thread from the JNIEnv:
JavaThread* thread = JavaThread::thread_from_jni_environment(env);
return thread->active_handles()->allocate_handle(obj);
but there is also another, faster, variant for when you already have the
"thread":
jobject JNIHandles::make_local(Thread* thread, oop obj) {
return thread->active_handles()->allocate_handle(obj);
}
When you look at the JNI_ENTRY wrapper (and related JVM_ENTRY, WB_ENTRY,
UNSAFE_ENTRY etc) it has already extracted the thread from the JNIEnv:
JavaThread* thread=JavaThread::thread_from_jni_environment(env);
and further defined:
Thread* THREAD = thread;
so we always already have direct access to the "thread" available (or
indirect via TRAPS), and in fact we can end up removing the
make_local(JNIEnv* env, oop obj) variant altogether.
Along the way I spotted some related issues with unnecessary use of
Thread::current() when it is already available from TRAPS, and some
other cases where we extracted the JNIEnv from a thread only to later
extract the thread from the JNIEnv.
Testing: tiers 1 - 3
Thanks,
David
-----
