[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