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

[Aleksey Shipilev]

On 05/03/2016 08:09 AM, Mikael Vidstedt wrote:
> 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/

Nice move overall!

unsafe.cpp:

*) Why do we Handle-ize incoming object in CompareAnd*? Is this because
we may acquire a mutex, and the object may be gone? Either way, I see
you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in
Unsafe_CompareAndExchangeLong -- why?

*) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before
acquiring a mutex -- now we don't do that in MemoryAccess.

vmSymbols.cpp:

*) {get|put}Address_raw intrinsics used to be conditionalized under
UseUnalignedAccesses. Baffles me why, because the old native code in
Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with
misaligned addresses. I wonder if the intent was to never fail, and then
we should really use Unsafe.{get|put}Unaligned in new Unsafe.java
{get|set}Address to dodge misalign faults?

library_call.cpp:

*) What is the point for doing this check:

2372   if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) {
2373     heap_base_oop = base;
2374   }

In old code heap_base_oop != top() only for heap ptrs, even if base is
NULL. In new code, if base is NULL, then heap_base_oop is top(). It
would seem that new code is better, because it clearly separates heap
vs. native accesses, and it does not seem to break anything downstream.
Was that the intent?

Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160503/1592b420/signature-0001.asc>