...and another one

[Andrew Haley]

I think this one is even more interesting than the store barrier
problem.

    public volatile Object referent;
    public final WeakReference<Object> ref;
    public final ReferenceQueue<Object> refQueue;

    public WeakReferenceTest() {
        referent = new Object();
        refQueue = new ReferenceQueue<>();
        ref = new WeakReference<>(referent, refQueue);
    }

    @Actor
    public void actor1() {
        while (ref.get() != null) {
            // burn!
        }
    }

So, actor1 is spinning in a loop, waiting for ref.get() to become
null.  This won't happen until a GC, and this will be a safepoint.
However, the code Graal generates is:

  0x0000007f8546e5f0: mov	x0, #0x7000                	// #28672
                                                ;   {poll}
  0x0000007f8546e5f4: movk	x0, #0x926b, lsl #16
  0x0000007f8546e5f8: movk	x0, #0x7f, lsl #32  ; ImmutableOopMap{c_rarg1=Oop }
                                                ;*aload_0 {reexecute=1 rethrow=0 return_oop=0}
                                                ; - org.openjdk.jcstress.tests.interrupt.WeakReferenceTest::actor1 at 0 (line 63)

  0x0000007f8546e5fc: ldr	wzr, [x0]       ;   {poll}
  0x0000007f8546e600: b	0x0000007f8546e5f0

Wow!  This is an infinite loop with a safepoint check in the middle.
Graal apparently doesn't believe that values can change from non-null
at a safepoint.  C2 seems to treat safepoints specially in this
regard.

Yes, I'll file a bug report.  Is it the case that effectively all of
the discussion about Graal bugs goes into the Github bug discussions?

Andrew.