RFR (M) 8152753: C1 intrinsics for CompareAndExchange (x86)

[Aleksey Shipilev]

On 04/07/2016 01:17 PM, Andrew Haley wrote:
> On 07/04/16 10:48, Aleksey Shipilev wrote:
>> On 04/07/2016 12:33 PM, Andrew Haley wrote:
>>> On 07/04/16 09:55, Aleksey Shipilev wrote:
>>>> On 04/07/2016 11:51 AM, Andrew Haley wrote:
>>>>> I'm very tempted to review this, but there is a rather odd thing:
>>>>> the bug does not explain the motivation for this change.
>>>>
>>>> Not following you.
>>>>
>>>> What motivation do you need apart from "...the rest of new Unsafe
>>>> methods that are not intrinsified by C1 are handled by Java fallbacks in
>>>> Unsafe.java. compareAndExchange cannot be emulated with existing APIs"?
>>>
>>> As far as I know all of these are handled by native methods.
>>> Is that not correct?  They seem to be.
>>
>> Yes. This is not a question on implementing CompareAndExchange: it is
>> handled by unsafe.cpp bits well, and this is why runtime can work even
>> without getting compilers in picture.
> 
> I thought so.
> 
>> This is about getting CompareAndExchange support in C1 in sync with
>> CompareAndSet support. C1 intrinsifies CompareAndSet to dodge native
>> calls, and should do the same for new CompareAndExchange.
> 
> So, this is entirely about making C1-generated code more efficient,
> by avoiding native calls.  Right?

Yes. The same reason why CompareAndSwap and {get,put}* are intrinsified
by C1.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160407/6b321155/signature.asc>