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

[Doerr, Martin]

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.