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

[Lindenmaier, Goetz]

Hi

> >	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.
Well, if it's NoEscape it's safe to remove the barriers wrt. to Java semantics, 
no matter what other optimizations (here: scalar replacement) do.  But here 
we look at the importance of the barrier to the runtime system, which is 
VM implementation specific. 
In particular, the new optimization addresses also objects that escape, as long
as they don't escape before the barrier at the end of the constructor.

Best regards,
  Goetz.


> On Thu, Dec 17, 2015 at 12:58 PM, Doerr, Martin <martin.doerr at sap.com
> <mailto: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
> <mailto:aph at redhat.com> ]
> 	Sent: Donnerstag, 17. Dezember 2015 16:44
> 	To: Hui Shi <hui.shi at linaro.org <mailto:hui.shi at linaro.org> >
> 	Cc: Doerr, Martin <martin.doerr at sap.com
> <mailto:martin.doerr at sap.com> >; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >;
> Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com> >;
> Aleksey Shipilev <aleksey.shipilev at oracle.com
> <mailto:aleksey.shipilev at oracle.com> >; Vladimir Kozlov
> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com> >;
> hotspot compiler <hotspot-compiler-dev at openjdk.java.net
> <mailto:hotspot-compiler-dev at openjdk.java.net> >; aarch64-port-dev
> <aarch64-port-dev at openjdk.java.net <mailto:aarch64-port-
> dev at openjdk.java.net> >; Mikael Gerdin <mikael.gerdin at oracle.com
> <mailto:mikael.gerdin at oracle.com> > (mikael.gerdin at oracle.com
> <mailto:mikael.gerdin at oracle.com> ) <mikael.gerdin at oracle.com
> <mailto: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.
> 
>