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

[Lindenmaier, Goetz]

Yes, there is no stack allocation.
But locks are removed, see escape.cpp:1844, which is executed under
condition not_global_escape(). As well look at callnode:1770.

Also, does_not_escape_thread() used here checks for <= ArgEscape.

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.

And, the constructor could be inlined (or does this happen after expand_allocate_common()?)

Best regards,
  Goetz.


From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Dienstag, 15. Dezember 2015 16:11
To: Andrew Haley <aph at redhat.com>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Doerr, Martin <martin.doerr at sap.com>; Aleksey Shipilev <aleksey.shipilev at oracle.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; Hui Shi <hui.shi at linaro.org>; 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

Yes that was my fault; I had forgotten about the ArgEscape analysis result.

To answer your question somewhat, if an object is NoEscape then it's scalar replaced in the end.  I don't think there's any other end result in hotspot (e.g there's no stack allocation).

On Tuesday, December 15, 2015, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
On 12/15/2015 02:51 PM, Vitaly Davidovich wrote:
> Hotspot implements only the scalar replacement form of EA.

Scalar replacement is not a form of escape analysis.  This does
not answer my question, which was:

> Are you saying that if escape analysis determined that an object does
> not escape then you know *for sure* that it will always be scalar-
> replaced?

Andrew.


--
Sent from my phone