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

[Vladimir Kozlov]

I agree with Aleksey. Clean up should be done separately, please, file RFE. This changes are already big.

Thanks,
Vladimir

On 2/17/16 11:46 AM, Aleksey Shipilev wrote:
> 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
>>
>
>