RFR (M) 8249650: Optimize JNIHandle::make_local thread variable

[David Holmes]

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
-----