RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor

[Claes Redestad]

Hi,

compilers can't see though and optimize away the repeated GetObjectField
calls in places such as in the io_util_md.h GET_FD macro:

#define GET_FD(this, fid) \
     (*env)->GetObjectField(env, (this), (fid)) == NULL ? \
         -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, 
(this), (fid)), IO_fd_fdID)

This can be avoided if we turn the macros into functions which call
GetObjectField only once:

FD getFD(JNIEnv *env, jobject this, jfieldID fid) {
   jobject fd = (*env)->GetObjectField(env, this, fid);
   if (fd == NULL) {
     return -1;
   }
   return (*env)->GetIntField(env, fd, IO_fd_fdID);
}

The similarly affected SET_FD is only used in one place, so I removed
that macro and applied the equivalent optimization at the call-site.

Webrev: http://cr.openjdk.java.net/~redestad/8244936/open.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8244936

This shows an improvement on the existing RandomAccessRead.test micro:

Before:
Benchmark                (fileSize)  Mode  Cnt  Score   Error  Units
RandomAccessRead.test       1000000  avgt   25  0.832 ± 0.001  us/op

After:
Benchmark                (fileSize)  Mode  Cnt  Score   Error  Units
RandomAccessRead.test       1000000  avgt   25  0.771 ± 0.005  us/op

~60ns/op overhead reduction - or ~30ns per native call (the micro calls
RAF::seek followed by RAF::read).

Since it's an improvement to the constant call overhead, relative gain
diminishes for larger operations, e.g., reading a 512b buffer sees only
~2% improvement, while already on a 8kb read the improvement is more or
less the noise. I added a read-into-buffer variant of the micro that
demonstrates.

Still, constant overhead is constant overhead, and operations that only
read a few bytes is common enough, for example when opening zip files,
so there's a fair chance for a positive effect in various places. As a
bonus this refactoring shrinks libjava by a few Kb.

Testing: tier1-2

Thanks!

/Claes