Fix (over) optimization for cmp-objects

[Roman Kennke]

Back when I implemented the cmp-objects-barrier, I was thinking we
could optimize it away if only *one* of the operands was coming from an
allocation. The logic being that in this case we know it's in to-space
already, and a false negative could not happen.

However, working on i-u, I realized this is wrong. What can happen is
that while that one operand comes from an allocation, it could be
'behind' a safepoint. This is not a problem in itself, because we
ensure at safepoints to evacuate those in-flight operands. However, we
cannot know that that the other operand is in to-space too. Let's say A
has been allocated before the safepoint, and then written to a field.
Then, at a safepoint, we target the region containing A for evacuation,
and initially evacuate A to A'. We also update the in-flight variable a
to point to A'. Then, after the safepoint, we load the field to b,
which still points to A. If we now compare a and b, we *do* need the
acmp barriers, because b still points to A. However, our current
optimization would remove the acmp barriers.


Notice that this problem was much more pronounced with my (not
published yet) incremental-update work, because with SATB we consider
all new object live, and thus would very likely never collect regions
that have been allocation regions before the safepoint (because they
are usually near 100% live). With i-u, even allocation regions are very
likely to be targeted for evacuation, and thus much more likely to
trigger this bug. However, while it's unlikely with SATB, it is not
impossible.

This fixes it:
http://cr.openjdk.java.net/~rkennke/cmpalloc/webrev.00/

Notice that the operands are still subject to optimizing away, but not
the whole acmp-barrier. I.e. in the above scenario, the 'a' operand
might still get optimized away because it's coming from an allocation.

Tested by running SPECjvm all night, especially compiler benchmarks,
which tended to create problems.

Ok to push?

Roman