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

Mikael Vidstedt mikael.vidstedt at oracle.com
Tue May 3 05:09:30 UTC 2016

Please review the following changes:

Bug: https://bugs.openjdk.java.net/browse/JDK-8150921
Webrev (jdk): 
Webrev (hotspot/): 

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


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.


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

More information about the hotspot-compiler-dev mailing list