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

[Lindenmaier, Goetz]

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