RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles
Andrew Dinn
adinn at redhat.com
Mon Feb 15 13:23:03 UTC 2016
Hi Alexsey,
On 15/02/16 12:22, 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 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.
Which platforms does that include? Specifically, does this
include/exclude non-closed AArch64?
> e) C2 intrinsics for x86:
>
> * Most intrinsics code is covered by platform-independent
> LibraryCallKit changes, which means non-x86 architectures are also
> partially covered.
The volatile stuff looks ok for Aarch64 after a quick eyeball scan.
However, I would like to check the code generated by the back end. I'm
especially interested in any potential interaction with Roland's patch
for 8087341 (which required associated AArch64 back end changes). I
think the two patches should combine correctly (and probably
commutatively) but it is worth checking.
> * 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.
Agreed, this is probably best left as a separate step for AArch64. I
think we will still be able to optimize the new CAS variants effectively
in the back end using the same technique as is employed for volatile
stores and standard CAS.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)
More information about the jdk9-dev
mailing list