RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles
coleen.phillimore at oracle.com
Thu Jan 28 21:04:16 UTC 2016
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.
>> Is the implementation of these mostly in
> 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:
More information about the hotspot-dev