RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles
vladimir.kozlov at oracle.com
Mon Jan 25 18:33:34 UTC 2016
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?
On 1/25/16 8:32 AM, Aleksey Shipilev wrote:
> I would like to solicit reviews for the slab of VM changes to support
> JEP 193 (VarHandles). This portion covers new Unsafe methods.
> 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
> * 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:
More information about the hotspot-dev