RFR: 8261493: Shenandoah: reconsider bitmap access memory ordering

[Zhengyu Gu]

On Fri, 12 Feb 2021 07:31:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Now, you need load barrier on read side (e.g. ShenandoahMarkBitMap::at()). Although, it is not a correctness issue, but seeing stale value means extra unnecessary work.
> 
> I don't see why. Adding load barriers would not affect promptness of seeing the memory updates to the bitmap itself. It might affect the promptness of seeing the object contents that we are reading after asking `is_marked` -- but that would be a race either way, because we do not use mark bitmap for memory ordering at all (i.e. there is no "release" on bitmap update).

The `load barrier` I were thinking, is something that can prompt seeing the updating of bitmap. I did a little digging, it does not seem we have something like that.

We rarely call is_marked() and variants during mark phase, except SATB filtering. I wonder if adding a leading fence in SH::requires_marking() can accomplish that. Although, it is still a race, but I think 1) small price to pay compares to the work of enqueuing a marked oop 2) might help the termination by not enqueuing marked oops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2497