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

[Vladimir Kozlov]

Using hotspot-dev instead and added jdk9-dev mailing lists.

Changes affect not only JIT (yes, most changes are JIT related). 
Specifically prims/unsafe.cpp changes.

There are no C1 changes?

Vladimir

On 1/25/16 8:32 AM, Aleksey Shipilev wrote:
> Hi,
>
> I would like to solicit reviews for the slab of VM changes to support
> JEP 193 (VarHandles). This portion covers new Unsafe methods.
>
> Webrev:
>   http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/
>   http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/
>
> The patches "almost" pass JPRT, with some failures in closed code,
> triggered by adding a large number of new intrinsics. Those failures are
> to be addressed separately -- and because of that, this change is not
> yet pushable. A preliminary review would be appreciated meanwhile.
>
> A brief summary of changes:
>
>   a) jdk.internal.misc.Unsafe has new methods. Since we now have split
> s.m.Unsafe and j.i.m.Unsafe, this change "safely" extends the private
> Unsafe, leaving the other one untouched.
>
>   b) hotspot/test/compiler/unsafe tests are extended for newly added methods.
>
>   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.
>
>   d) C2 intrinsics for x86:
>
>     * Most intrinsics code is covered by platform-independent
> LibraryCallKit changes, which means non-x86 architectures are also
> partially covered.
>
>     * There are two classes of ops left for platform-dependent code:
> WeakCAS and CompareAndExchange nodes. Both seem simple enough to do, but
> there are details to be sorted out on each platform -- let's do those
> separately.
>
>     * Both LibraryCallKit::inline_unsafe_access and
> LCK::inline_unsafe_load_store were modified to accept new access modes,
> and generally brushed up to accept the changes.
>
>     * putOrdered intrinsic methods are purged in favor of put*Release
> operations. We still keep Unsafe.putOrdered for testability and
> compatibility reasons.
>
> Eyeballing the generated code on x86 yields no obvious problems. Sanity
> microbenchmark runs do not show performance regressions on old methods,
> and show the expected performance on new methods:
>    http://cr.openjdk.java.net/~shade/8148146/notes.txt
>
> Cheers,
> -Aleksey
>