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

[Hui Shi]

Thanks Andrew and Martin!

Agree, it's better fix original storestore barrier optimization with escape
information.

When entering PhaseMacroExpand::expand_allocate_common, object must be
allocated on heap and can't be scalar replaced? This issue can't be solved
by detecting unsafe publish only in constructor, in following example, b is
published outside constructor and storestore barrier still can't be removed.
  public void TestMethod() {
    A a = new A();
    dont_inline_me();
    //System.gc();
    B b = new B(); // empty constructor
    // nosafe point
    a.b = b;
  }

Martin proposed fix looks reasonable, disable original storestore barrier
optimization if GC threads might reference allocated object.

Regards
Hui

On 18 December 2015 at 01:58, Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi Andrew,
>
> thanks for your emails.
>
> Many memory barriers are only there for concurrent java threads and are
> not relevant for GC. They are opportunities for EscapeAnalysis-based
> optimizations.
>
> The MemBarStoreStore after the Allocation actually has this purpose plus
> the additional purpose to satisfy GC requirements. EscapeAnalysis was not
> designed to analyze "escape to concurrent GC". I guess it is difficult to
> analyze this in general.
>
> So maybe it would be better to change the condition for the
> MemBarStoreStore barrier insertion to something like
> "gc_requires_initialized_new_obj_headers() || !alloc->does_not_escape..."
> with the first function containing the knowledge about all GCs.
>
> You also had asked if the objects in my example were scalar replaced. By
> default, they do get scalar-replaced, but I had prevented this by
> -XX:-EliminateAllocations which does not influence the escape state and the
> membar optimizations.
>
> Best regards,
>  Martin
>
> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Donnerstag, 17. Dezember 2015 16:44
> To: Hui Shi <hui.shi at linaro.org>
> Cc: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz <
> goetz.lindenmaier at sap.com>; Vitaly Davidovich <vitalyd at gmail.com>;
> Aleksey Shipilev <aleksey.shipilev at oracle.com>; Vladimir Kozlov <
> vladimir.kozlov at oracle.com>; 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: RFR: 8144993: Elide redundant memory barrier after
> AllocationNode
>
> The potential problem only arises if "this" is published unsafely and
> the object to which it is published doesn't escape.
>
> Can't we detect unsafe publication?  It ought to be easier than escape
> analysis: it's a matter of detecting that "this" escapes from the
> constructor.
>
> Andrew.
>