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

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Feb 15 13:49:24 UTC 2016


Hi Andrew,

On 02/15/2016 04:23 PM, Andrew Dinn wrote:
> 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?

Yes, open AArch64 is included there. But now I realize new Unsafe tests
have not been run there, let me manhandle our infra into doing that. If
that is easy for you, can you check if AArch64 works with this patch in
your scenarios?


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

The changes are supposed to generate the same code for old Unsafe
methods -- the refactoring shuffles the compiler code around, but the
sequence of accesses/barriers should stay the same. Eyeballing x86_64
assembly indeed shows it is the same, but I haven't looked beyond x86.

So Roland's patch and those super-(awe|grue)some ARM64 .ad matchers
should be unaffected. If they are affected, then I screwed up somewhere
during refactoring. I'll wait for Roland's patch to land before pushing
these Unsafe changes anyway, and beef up on testing.

Thanks,
-Aleksey



More information about the jdk9-dev mailing list