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

[Hui Shi]

Thanks Martin!

Could discussion limit to 8144993 in this thread. Stated in early mail, it
looks safe in 3 cases for references from both GC thread or other java
thread.

8136596 enhances original optimization from noEcape to both noescape and
argescape. As said in your new example, both allocations are noescape, so
it's not directly related with 8136596.  How about starting a new thread
discussing if there is possible danger in original storestore  barrier
optimization?

Regards
Hui

On 17 December 2015 at 21:59, Andrew Haley <aph at redhat.com> wrote:

> On 12/17/2015 01:54 PM, Doerr, Martin wrote:
>
> > So you can see that both Allocations have the state NoEscape, but
> > there’s a safepoint (the non-inlined call) between them. Concurrent
> > GC could access the obj header and read stale data (and possibly
> > crash). OptoAssembly shows that the MemBar was optimized out
> > (probably due to 8136596).
> >
> > However, we may have luck. Maybe no concurrent GC accesses the
> > header of newly created objects. But I don’t know if this is true
> > which is the reason why I posted this question originally. Keep in
> > mind that objects can get allocated in old gen.
>
> So, they are both NoEscape.  So do the objects actually get allocated?
> Or are they scalar-replaced?
>
> Andrew.
>