RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants

[Mikael Vidstedt]

Please review the following changes:

Bug: https://bugs.openjdk.java.net/browse/JDK-8150921
Webrev (jdk): 
http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/
Webrev (hotspot/): 
http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/

* Summary (see bug for some additional information)

There are two versions of the Unsafe getter/setter methods: one which 
takes an Object and a long, and one which takes a single long argument. 
For example:

float getFloat(Object o, long offset);
float getFloat(long address);

The two-argument (aka. double-register) version can operate both on Java 
heap data (if o is non-null) and data in native memory (if o is null). 
The latter, single-register version only supports native data, and 
behaves exactly like the corresponding double-register version with an 
'o' argument of null. This change updates Unsafe.java to make the 
single-register versions do exactly that - call the double-register 
version with a first 'null' argument. Doing this on the Unsafe.java 
level means means that the VM only needs to implement support for a a 
single set of the primitives, and most of the rest of the changes are 
removing the code related to the (now) dead intrinsics. However, the 
changes in library_call.cpp are a bit less straightforward, so I would 
appreciate a detailed review of those changes in particular.

To reduce the risk of any performance regressions the single-register 
methods have all been annotated with @ForceInline.

This change also introduces a helper class called "MemoryAccess" in 
unsafe.cpp, which unifies and encapsulates the logic needed to perform 
the different types of memory accesses. Specifically, the class captures 
logic to:

- use the right C++/Hotspot primitives for performing normal, volatile 
and mutex guarded memory accesses respectively
- normalize the stored values
- set and restore the doing_unsafe_access state in the thread if needed 
(checked by the signal handler in case a SIGBUS signal is raised)


* Testing:

I have used the following test to drive the development of this change:

http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java

Unfortunately, the test doesn't work reliably unless also applying some 
workaround changes the problem of the SIGBUS related exceptions not 
being thrown synchronously. Making the delivery synchronous is covered 
by [1]. I added the test as an attachment to [1] for future use.

In addition to the above test I have run the normal JPRT smoke testing. 
I will also run some additional testing before pushing, but feel like 
this is a good time to get some feedback.

Cheers,
Mikael

[1] https://bugs.openjdk.java.net/browse/JDK-8154592