RFR: JDK-8207169: X86: Modularize cmpxchg-oop assembler for C1 and C2

[Roman Kennke]

I guess we could emit a branch to a cmpxchg-stub instead of cmpxchg-lir and generate that via the usual interfaces in BarrierSetAssmbler. It's less efficient though. Alternatively we could make a new lir instruction for this, same idea as for C2 basically.

Roman


Am 31. August 2018 16:35:30 MESZ schrieb Erik Osterlund <erik.osterlund at oracle.com>:
>Hi Roman,
>
>> On 31 Aug 2018, at 16:26, Roland Westrelin <rwestrel at redhat.com>
>wrote:
>> 
>> 
>> Hi Erik,
>> 
>>> So if you have some kind of loop for your CAS, your
>>> ShenandoahBarrierSetC1 can generate the LIR for that, and allocate
>>> registers accordingly, letting the register allocator do its thing.
>> 
>> I doubt it's as simple as you make it sound. A loop or any control
>flow
>> construct would require us to hack the CFG. In c1, the CFG is
>> constructed at parse time from the bytecodes of the method being
>> compiled. There's no code that I know of that changes the CFG once
>> parsing is over. The c1 way of doing something like that is to
>implement
>> the loop (or any control flow) in assembly code in the backend.
>
>Well... C1 uses CAS in the heap only for the Unsafe CAS intrinsic,
>which is indeed inserted at parse time. And all other GCs alter the CFG
>for the GC barriers in their CAS barriers, using LIR. Except Epsilon I
>suppose.
>
>Thanks,
>/Erik
>
>> Roland.