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

[Vitaly Davidovich]

Ok, as I just replied to Andrew, I hadn't considered the ArgEscape
scenario.  Does an oop that's ArgEscape still get allocated on heap then?

On Tue, Dec 15, 2015 at 9:37 AM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> If object arg_escape, locking, barriers etc can be relaxed, but scalar
> replacement is not possible.
>
> Oop maps are needed, else these don’t survive the gc.
>
>
>
> Goetz.
>
>
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Dienstag, 15. Dezember 2015 15:29
> *To:* Andrew Haley <aph at redhat.com>
> *Cc:* Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Doerr, Martin <
> martin.doerr at sap.com>; Aleksey Shipilev <aleksey.shipilev at oracle.com>;
> Vladimir Kozlov <vladimir.kozlov at oracle.com>; Hui Shi <hui.shi at linaro.org>;
> hotspot compiler <hotspot-compiler-dev at openjdk.java.net>;
> aarch64-port-dev <aarch64-port-dev at openjdk.java.net>; Mikael Gerdin <
> mikael.gerdin at oracle.com> (mikael.gerdin at oracle.com) <
> mikael.gerdin at oracle.com>
> *Subject:* Re: [aarch64-port-dev ] RFR: 8144993: Elide redundant memory
> barrier after AllocationNode
>
>
>
> 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.
>
>
>