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):
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
More information about the hotspot-compiler-dev
mailing list