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

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Apr 7 09:48:48 UTC 2016

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.

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.

In other words, out of the realm of VarHandles accessor methods, we are
either covered by Unsafe.java shortcuts, or C1/C2 intrinsics that
replace unsafe.cpp calls. Except for CompareAndExchange, until this RFE.


-------------- 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/9ed9e0fb/signature.asc>

More information about the hotspot-compiler-dev mailing list