RFR: 8261493: Shenandoah: reconsider bitmap access memory ordering

[Aleksey Shipilev]

On Fri, 12 Feb 2021 13:16:03 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> 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.

I suspect it would not help much, mostly because hardware does not hoard mutable data on the timescales that are important for performance (they do it on timescales that are important for correctness though: data coming out of order "just" 100ps later is still out of order). I believe we would be paying barrier costs for a very little gain in promptness. Our current handshaking-before-final-mark and SATB locking provides enough of memory bashing, I think.

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

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