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

Hui Shi hui.shi at linaro.org
Tue Dec 15 14:50:38 UTC 2015


Thanks All!

In Goetz example, suppose the outer method is named foo and object a, b is
not escaped in foo. b is not escaped in foo as a is not escaped in foo.

But b is escaped in its initializer in BCEscapeAnalysis. In b's initializer
method, "this" should be marked escaped as it is assigned to another
parameter "assign to a.x". As b is escaped in its initializer, storestore
barrier will not be removed in this case, so it's safe.

Regards
Hui

On 15 December 2015 at 21:53, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
wrote:

> Hi Andrew,
>
> 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
>     }
>
> Best regards,
>   Martin and Goetz.
>
>
> > -----Original Message-----
> > From: Andrew Haley [mailto:aph at redhat.com]
> > Sent: Dienstag, 15. Dezember 2015 14:46
> > To: 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
> >
> > Hi,
> >
> > On 12/15/2015 01:09 PM, Lindenmaier, Goetz wrote:
> >
> > > What if it's assigned to an object that's already completely alive,
> > > but does not escape itself?
> >
> > It's not clear to me exactly what this means.  However, if neither
> > object escapes then they are both reachable to GC only via scanning
> > the stack, and this can happen only at safepoints.
> >
> > Andrew.
>
>
>
>


More information about the aarch64-port-dev mailing list