[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