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

[Hui Shi]

Thanks Andrew, Goetz and all!

Major concern is will removing storestore barrier cause other threads read
stale data for newly allocated object. Other threads include java thread or
concurrent GC thread. It should be safe with following analysis.

1. If BCEA result "this"(b) escapes in its initializer, change will not
optimize storestore barrier.
2. If BCEA result "this"(b) does not escape in its initializer, it's safe
to remove storestore.
   2.1 If there is a safe point between storestore and release, b is
visible to GC in initializer, but at safe point, it should have a memory
barrier.
   2.2 If there is no safe point between storestore and release. b will be
visible to other thread after release memory barrier.

Case #1
A a = new A();
safepoint // a can be reached from GC
new B(a)

allocation
-------
b.klass =...
b.markword =...
b.f1 = 0
..
b.fn = 0
storestore
-------- init start
....
a.x = this;  // b might visible to other threads here
....
release
-------- init end

BCEA result indicate "this"(b) is not local and not arg_stack. So "b" will
be treated as escaped in its initialzer, so change will not optimize
storestore barrier.
[EA] estimated escape information for B::<init>
     non-escaping args:      {}
     stack-allocatable args: {1}
     return non-local value
     modified args:     0x6    0x6
     flags:
b="this"  is not local and not arg_stack
a        is arg_stack means it is passed in and not assigned to other
object in initializer.

Case #2.1
allocation
-------
b.klass =...
b.markword =...
b.f1 = 0
..
b.fn = 0
storestore
-------- init start
....
safepoint  // "this" is in oop map and might visible to GC thread here
....
release
-------- init end

Case #2.2
allocation
-------
b.klass =...
b.markword =...
b.f1 = 0
..
b.fn = 0
storestore
-------- init start
....
release
-------- init end

Regards
Hui

On 16 December 2015 at 00:15, Andrew Haley <aph at redhat.com> wrote:

> On 12/15/2015 04:01 PM, Lindenmaier, Goetz wrote:
>
> > Further, if the object is NoEscape it might not be scalar
> > replaced. If I remember correctly, there are various conditions,
> > e.g., too big, allocated in loop.
>
> Well, that's the killer.  The definition of "escape" we need to use
> here is the really, truly, honest-to-goodness one: that this object
> never becomes visible to any other thread by any means.  Unless that
> is so, all bets are off.  In this case, what is intended is "appears
> in an OOP map".
>
> Andrew.
>