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

[Lindenmaier, Goetz]

Hi Andrew,

What if it's assigned to an object that's already 
completely alive, but does not escape itself?

Best regards,
  Goetz.


> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> bounces at openjdk.java.net] On Behalf Of Andrew Haley
> Sent: Dienstag, 15. Dezember 2015 11:42
> To: 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
> 
> On 15/12/15 10:27, Doerr, Martin wrote:
> 
> > I think this change is good with respect to concurrent java threads.
> > However, I'm not sure if concurrent GC may have a problem when we
> > optimize out the memory barrier (with or without this change).
> >
> > Is it guaranteed that no concurrent GC will ever read an object
> > header of such a newly allocated object?
> > A reference to this object may get written somewhere where GC can
> > find it. If the GC reads the header, it may read stale data.
> 
> We know that the reference to the newly-created object does not
> escape, so it is not reachable from any reference.  The only other way
> a GC might find it is at a safepoint.  But even if that happens, a
> safepoint is a memory barrier.  So I think we're OK.
> 
> Andrew.