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

[Vitaly Davidovich]

>
> 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.


I'd say that's a big problem, no? The membar elimination is only safe if
the allocation is actually removed.  If the analysis says it's NoEscape but
compiler still allocates it for whatever reason (Goetz mentioned a couple
earlier in this thread), then it seems insufficient to rely on just the
analysis result.

On Thu, Dec 17, 2015 at 12:58 PM, 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.
>