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

[Lindenmaier, Goetz]

Hi Hui

That depends how BCEscapeAnalysis is implemented.  I don’t know this in detail.
But in theory, after analyzing a callee, you represent it by some function
describing it’s semantics. From this you would derive that both are ArgEscape in the end.

Best regards,
  Goetz.


From: Hui Shi [mailto:hui.shi at linaro.org]
Sent: Dienstag, 15. Dezember 2015 15:51
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; Aleksey Shipilev <aleksey.shipilev at oracle.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; 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

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<mailto: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<mailto:aph at redhat.com>]
> Sent: Dienstag, 15. Dezember 2015 14:46
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Doerr, Martin
> <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>; Aleksey Shipilev <aleksey.shipilev at oracle.com<mailto:aleksey.shipilev at oracle.com>>;
> Vladimir Kozlov <vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>>; Hui Shi <hui.shi at linaro.org<mailto:hui.shi at linaro.org>>;
> hotspot compiler <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>; aarch64-port-
> dev <aarch64-port-dev at openjdk.java.net<mailto:aarch64-port-dev at openjdk.java.net>>; Mikael Gerdin
> <mikael.gerdin at oracle.com<mailto:mikael.gerdin at oracle.com>> (mikael.gerdin at oracle.com<mailto:mikael.gerdin at oracle.com>)
> <mikael.gerdin at oracle.com<mailto: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.