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

[Aleksey Shipilev]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160125/11885fdb/signature.asc>