RFR #2 (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. The last
review got fallen through the mailing list trenches with reposts,
hopefully we will have more reviews now that we include hotspot-dev and
jdk9-dev.

Webrev:
  http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.01/
  http://cr.openjdk.java.net/~shade/8148146/webrev.hs.01/

These changes successfully pass JPRT -testset hotspot on all platforms.

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

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) C1 intrinsics are not present in this patch: we have some
prototypes in VarHandles forest, but they are not ready to be pushed;

  e) 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.

Cheers,
-Aleksey