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

[Coleen Phillimore]

On 1/27/16 4:09 AM, Aleksey Shipilev wrote:
> Hi Coleen,
>
> On 01/26/2016 06:49 PM, Coleen Phillimore wrote:
>> 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.
> vmSymbols depends on vmIntrinsics:
>
> #define VM_SYMBOLS_DO(template do_alias)
>   ...
>
>    /* class symbols needed by intrinsics */
>    VM_INTRINSICS_DO(VM_INTRINSIC_IGNORE, template, VM_SYMBOL_IGNORE,
> VM_SYMBOL_IGNORE, VM_ALIAS_IGNORE)
>
> Therefore, splitting out vmIntrinsics would mean vmSymbols would have to
> include vmIntrinsics anyway, so I don't see the benefit of doing that
> within this patch.

The benefit is encapsulation, but they mutually depend on each other, so 
it's not that easy.

Coleen
>
>>   Is the implementation of these mostly in
>> library_call.cpp?
> C2 intrinsics are implemented in library_call.cpp. The subsequent
> patches would probably bring C1 intrinsics as well, which will reference
> the same vmIntrinsic symbols.
>
>
>> 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.
> Well, I grepped through SA code, and see no references even for the
> existing CompareAndSwap nodes. Which makes me to believe we would just
> want to communicate the nodes appropriately through vmStructs table, and
> be done. This is what the patch already does.
>
>
>> There might be changes to jvmciStructs though.  I don't know.
> I grepped through JVMCI, and found no clear dependencies, except for
> referenced MH intrinsics, that are not affected by this patch.
>
>
>>> On 1/25/16 8:32 AM, Aleksey Shipilev wrote:
>>>> Webrev:
>>>>    http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/
>>>>    http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/
> Cheers,
> -Aleksey
>
>