[aarch64-port-dev ] RFR: 8144993: Elide redundant memory barrier after AllocationNode

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 15 14:28:35 UTC 2015


I'm curious why you guys think `a` and/or `b` would be in the oopmap if
compiler proves they don't escape.  AFAIK, both `a` and `b` will be
component-wise scalar replaced.  Once that's done, there's a ref from
scalar replaced a.x to `b`, but `b` itself is scalar replaced.  In either
case, I don't see why either of these need to be known to GC at all (which
would somewhat defeat the purpose of EA to begin with).

On Tue, Dec 15, 2015 at 9:05 AM, Andrew Haley <aph at redhat.com> wrote:

> Hi,
>
> On 12/15/2015 01:53 PM, Lindenmaier, Goetz wrote:
>
> > here an example:
> >
> > A a  = new A ();      // a does not escape
> > Safepoint();             // a is known to GC
> >                                      // Concurrent GC is running.
> > B b = new B(a);
> >
> >     where
> >     B(A a) {
> >          <Initialize>
> >          StoreStore barrier  // This is removed by the optimization.
> >         a.x = this;                    // Then this is not initialized,
> but visible to GC
> >         final field store
> >         Membar_release
> >     }
>
> Hmm, interesting.  Here we're presented with two objects which
> escape analysis reveals as not escaping but both are allocated
> anyway and are included in the OOP map.
>
> I'd argue that once you've put an object into an OOP map to be scanned
> it has escaped, but that may well not be how C2 handles it.  For this
> reachability analysis to be correct, if you put a reference to an
> object into any object which is reachable as a GC root then that object
> surely does escape.
>
> Andrew.
>


More information about the aarch64-port-dev mailing list