Questions about CompareAndSwap

[Roman Kennke]

Am Samstag, den 21.11.2015, 00:35 +0300 schrieb Aleksey Shipilev:
> Hi Roman,
> 
> On 11/20/2015 06:31 PM, Roman Kennke wrote:
> > 2. Would it be possible to also get the actual old-value out of
> > CompareAndSwapP, in addition to the flags? My idea is that
> > CompareAndSwapP would be a MultiNode producing two outputs. Would
> > that
> > be possible? Would there be any disadvantages (i.e. loss of
> > performance
> > due to messed up optimizations, or such?)
> 
> Actually, VarHandles add new compareAndExchange methods, that are
> intrinsified with the new C1/C2 code. Those methods return old value
> on
> success, and expected value on failure (actually, they leave
> accumulator
> untouched on failure) -- pretty much what you expect from x86-style
> lock
> cmpxchg.
> 
> We already did prototypal x86_*.ad changes for them. See:
>  https://bugs.openjdk.java.net/browse/JDK-8136761
> 
> We are planning to sweep the implementation, and hit the review soon.

Great! Just to clarify: this is going to be a new intrinsic+opcode?
I.e. we will have one opcode that returns the 'flags' (except that it
doesn't, see my question 1), and one that returns the expected/previous
value, is that right? I really have a use for both, at the same time ;-
) However, I guess that getting the old value would do, I can compare
it to what's expected and get the flags that way.

I am aware of the possibility of subtle bugs when loading the value
from memory. I don't think that it's a problem for correctness in my
particular case. But I'd sleep better if I could just use what cmpxchg
gives me.

Now I'm thinking that maybe I should introduce my own opcode for
Shenandoah's cmpxchg-object and implement it in assembly in the
backend, using both the flag and 'return value' of the cmpxchg
instruction.

What do you think about my question #1 and suggested solution? I
believe that by using a ConditionalStoreP-like opcode, paired with
CMove, we'd get the same effect (I think CMove can be made sete+movzbl
when getting 0 and 1 as constant inputs), and we'd have an opportunity
to optimize away the middle part of cmpxchg->cmove->cmpi->bool and use
the flags directly.

Roman