RFR(S): 8237837: Shenandoah: assert(mem == __null) failed: only one safepoint

[Roman Kennke]

Hi Roland,

The patch looks ok to me. I have to admit that the actual semantics is
not 100% clear to me, so the review is on cosmetic level for the most
part. I'll trust you with the actual change ;-)

What sort of testing have you run to verify the change? Would be good to
cover at least hotspot_gc_shenandoah, and the CTW tests if this is
supposed to go into jdk14.

Do you expect any performance impact (esp a regression)?

Do we know if it also affects 11u and/or 8u? If so, update the bug entry
accordingly. Also, maybe also update the synopsis if you can think of a
better one (up to you).

Thanks,
Roman

> http://cr.openjdk.java.net/~roland/8237837/webrev.00/
> 
> At barrier expansion, raw memory needs to be correctly wired around
> expanded barriers. For that, the raw memory subgraph is walked starting
> from the Root node. When there's an infinite loop, the loop is connected
> to the Root node through a NeverBranch. So that logic looks for a
> NeverBranch from the Root node and if it finds one, it needs to find the
> memory state in the loop. The current logic looks for the SafePoint in
> the infinite loop. That breaks when the infinite loop has a SATB barrier
> because then the loop body has a runtime call for which is_SafePoint()
> returns true (eventhough the call doesn't safepoint). I've reworked the
> logic so it ignores non safepointing runtime call and is more robust for
> infinite loops.
> 
> Roland.
>