RFR: Barriers for locks rewrite

[Roman Kennke]

Ok, this took a little longer to sort out.

For now I decided to take out the platform specific parts. This 'only'
moves the barriers from outside the locking code to where the mark word
is actually touched. This results in much fewer write barriers all over
the place, and fixes the problem that when synchronizer or
biasedlocking pull out an oop from a Handle, it may no longer be in to-
space.

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

The platform specific parts will be addressed in a separate change, and
in a different way than originally intended.

Ok to commit now?

Roman


Am Montag, den 10.10.2016, 10:14 +0200 schrieb 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
>