RFR (M) 8152753: C1 intrinsics for CompareAndExchange (x86)
Andrew Haley
aph at redhat.com
Thu Apr 7 10:17:15 UTC 2016
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?
Andrew.
More information about the hotspot-compiler-dev
mailing list