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

[Coleen Phillimore]

Aleksey,

This might be a good time to split vmIntrinsics off from vmSymbols and 
create new .hpp and .cpp files for them.  There are a lot of both now 
and they're different.   Is the implementation of these mostly in 
library_call.cpp?

Also, if there are changes to vmStructs there are likely changes to the 
serviceability agent duplicated code.  If not, then there is no need to 
make changes to vmStructs.  There might be changes to jvmciStructs 
though.  I don't know.

Thanks,
Coleen

On 1/25/16 1:33 PM, Vladimir Kozlov wrote:
> 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?
>
> Vladimir
>
> On 1/25/16 8:32 AM, Aleksey Shipilev wrote:
>> 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
>>