The vm text patching mechanism will attempt to replace a call to a
single-instruction assembly-language stub with that single instruction.
Both the the call and the corresponding delay slot instruction must
be replaced simultaneously. We currently patch in membar, prefetch
and cas/casx instructions in this fashion. It is, however, incorrect
to do so for the latter, as a thread may execute the call, be suspended,
another thread may replace the call+delay slot, and the original thread
resume by executing a now changed delay slot instruction. If the
delay slot instruction is a cas, we will twice do a cas to the wrong place
or with the wrong compare or exchange value, resulting in an
unpredictable memory stomp and/or a sync failure.

The above problem almost never occurs due to the fact that the first use
of an atomic operation is almost always uncontended long enough for the
patch to be done, which is why, e.g., long bigapps runs have failed to
expose it. There is thus no smoking gun, though we have seen behavior
that may be caused by it when running jbb with the problem described
in bug 4523010.