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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Tue Dec 15 13:53:39 UTC 2015


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