...and another one

[Benoit Daloze]

Just curious, did you run the full jcstress suite?
I guess it would reveal a few problems due to missing barriers currently.

On Fri, Nov 18, 2016 at 7:14 PM, Andrew Haley <aph at redhat.com> wrote:

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