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?


More information about the hotspot-compiler-dev mailing list