RFR: Barriers for locks rewrite

[Roman Kennke]

Oh, and in my opinion, this also makes it more obvious why we need
barriers in those places at all: we read the mark-word -> need read-
barrier. We write the mark-word -> need write barrier.

 It also makes the code more consistent with the other field accessors
in oopDesc, and more resilient to future changes: having the barriers
in the accessors ensures that any code that uses those does The Right
Thing.

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
>