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

[John Rose]

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