RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

[Aleksey Shipilev]

Our hands were itching to remove these "duplicate" Unsafe methods for a
while now. But I think these cleanups should really be done separately
to catch mistakes. I'd like to keep this particular RFR for
VarHandle-specific entries only.

Cheers,
-Aleksey

On 02/17/2016 10:42 PM, John Rose wrote:
> One other point:  As long as you are massaging the library_call code,
> you could flush the *_raw versions of all the intrinsics:  All we need
> are the normal intrinsics (GETPUTOOP), not the one-address ones
> (GETPUTNATIVE), as long as Unsafe class (both of them) redirects
> one call to the other.
> 
> The *_raw (NATIVE) intrinsics should have been GC-ed a long time ago,
> given that the two-address version (OOP) is all anybody needs.
> 
> To avoid mishaps, a @ForceInline is needed on that kind of wrapper.
> 
> Mikael's forthcoming Unsafe changes are another place we could
> handle this cleanup.
> 
> — John
> 
>> On Feb 16, 2016, at 7:30 PM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> On Feb 15, 2016, at 4:22 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>>
>>> c) unsafe.cpp gets the basic native method implementations. Most new
>>> operations are folded to their volatile (the strongest) counterparts,
>>> hoping that compilers would intrinsify them into more performant versions.
>>
>> A simpler way to accomplish this would be to give the folded API points non-native method bodies, redirecting to whatever native they are folded to.
>>
>> This will move most of the folding choices up to Java code.  A fair amount of movement in unsafe.cpp will disappear.
>>
>> The non-native folded methods would still be marked @HSIC and be optimized accordingly.
>>
>> — John
>