RFC: Deoptimization bug

[Roman Kennke]

We've observed a rather nasty bug in some tests in jdk8u lately. From
what I can tell, this affects all versions though. I am not 100% sure
that what I'm thinking is correct, so let me describe it for further
discussion.

Deoptimization happens at safepoints. It may happen at a safepoint in
the middle of concurrent evac. In fact (but this is not really relevant
for the fix I think), evac threads might continue to run concurrently
with the deopt-safepoint. (We do have an option to make GC workers
synchronize at safepoints too, we might consider this.)

Deoptimization generates valid interpreter frames out of compiled
frames. One of the funny things it needs to do is recreate locks that
the compiler has eliminated (via escape analysis). In order to do this,
it creates a bunch of compiledVFrame objects that get populated with
on-stack-objects (or sometimes new objects, because it also needs to
recreate objects that have been eliminated because of escape analysis).
Those on-stack-objects may be from-space-copies. If such a
from-space-copy is subsequently passed to slow_enter() (to re-create the
lock), it will take the from-space-mark and write that into the
displaced header. This blows up later, of course.

A possible quick fix for this may be:
http://cr.openjdk.java.net/~rkennke/fix-locking.patch

But I'm not really happy with it. We probably should comb through
deoptimization.cpp and find the right places where we need to apply WB.

Roman