RFR: Barriers for locks rewrite

[Roman Kennke]

Hi there,

this is a bigger one.

The initial issue was an assert that complained about the mark word not
being neutral. It happened rarely. The issue was that for locking we
would always do a write barrier fairly early on, then pass that WB'ed
oop down to synchronizer.cpp and biasedLocking.cpp. Some code paths
wrap the oop into a handle, and later pull it out again. In particular,
biased locking can run into a safepoint, after which we do not
guarantee that the oop in the handle is still in to-space. It would
then go on and possibly (and rarely) write to a from-space oop.

I fixed this by moving the barriers to where the mark word is actually
accessed: a read-barrier in oopDesc::mark() and write-barriers for
oopDesc::set_mark(), oopDesc::release_set_mark() and
oopDesc::cas_set_mark().

It means we no longer need write-barriers in many places that somehow
called into synchronizer. Much less changes in shared code!

It means that we potentially don't need to invoke write-barriers for
locks at all: when we try to enter a lock, and the lock is already
biased towards our thread, then we only ever read the mark word, and
therefore only require a read barrier.

I also changed the interpreter and C1 to do the barriers late. Some
nasty code didn't use oopDesc::mark_offset_in_bytes() but just 0. I
fixed that.

I haven't changed this in c2 yet, currently discussing with Roland how
to do that. It does the barriers early still, and this is conservative
and ok.

Last but not least, the patch fixes the assert that got me going
initially :-)

Testing: I've run jcstress in quick mode, and will run more on a bigger
machine as soon as the change is in.

http://cr.openjdk.java.net/~rkennke/lockbarriers/webrev.00/

Ok?

Roman