When running this test we fail for different reasons. To catch the problem earlier one can run with -XX:+ZVerifyViews, to unmap the bad views and let the JVM crash when we have unhealed pointers.

When doing this, I got a crash in this code sequence:
ldr x16 [x20, #32]
ldr x14 [x20, #96]
<load barrier for x14>
ldr w12, [x16, #16] <= crash

x20 is a Java object, and offsets 32 and 96 corresponds to oops. The code shouldn't be allowed to dereference x16 without a load barrier, but it does.

Looking at the x20 objects I see that all oops have been healed with the current marked bit. That's probably because the marking thread has caught up and fixed all oops. x16 contains the non-fixed (remapped) value that we see in x20 + 96.

ZGC has super late expansion of the load barriers, but do have an even later optimization pass to look at the code about to be generated, and elides redundant loads. This is done in two ways:

1) Look at memory access within a block
2) Looking at use/defs accros blocks

If I turn off (1), this stops crashing.

Earlier versions of this had problems with "schedule and bundle" moving things around, causing problems for this optimization. In the code we have this comment to remind us:
  // Late barrier analysis must be done after schedule and bundle
  // Otherwise liveness based spilling will fail

But maybe something is still broken in this area.