Questions about CompareAndSwap

Roman Kennke rkennke at
Fri Nov 20 16:17:09 UTC 2015

> 1. Why do we do:
> cmpxchgq
> sete
> movzbl

Ok, I think I figured out the answer to that first question.
ConditionalStoreP can feed directly into a BoolNode, while
CompareAndSwapP must go through a CmpINode first.

I wonder if the CompareAndSwapP can be done like ConditionalStoreP,
with a CMove attached to it, and attempt to optimize away a
CompareAndSwapP->Bool->CMove->CmpI->Bool chain (which would be the
result of normal use-cases of CompareAndSwapP I guess) into
CompareAndSwapP->Bool ? Thus resulting in a direct use of the flags.

What do you think?


> I.e. do the CAS, then set 1 in the result register if ZF was set,
> then
> mask? A few lines up I see storePConditional, which does (to my eyes)
> *exactly* the same, except that it actually passes out the flags?
> It says there 'no flag versions of CompareAndSwap{P,I,L} because
> matcher can't match them' but why does it work for StorePConditional?
> 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?)
> In case you wonder why I need this, I need to do some special tricks
> to
> make CompareAndSwapP work correctly with Shenandoah, where an object
> can have a from-space and a two-space copy. I have an algorithm that
> works and is efficient enough, but it requires to get the previous
> value of the memory location. Currently I do this using an extra
> LoadP,
> but I guess it might be more efficient to use what I get out of the
> cmpxchg?
> Cheers,
> Roman

More information about the hotspot-compiler-dev mailing list