[RFR] Remove MemBarRelease when final field's allocation is NoEscape or ArgEscape
Aleksey Shipilev
aleksey.shipilev at oracle.com
Tue Sep 8 14:48:19 UTC 2015
Hi,
On 09/08/2015 03:41 PM, Hui Shi wrote:
> There might be better use of escape analysis result when optimizing
> MemBarRelease node for final field stores. Could anyone help review and
> comments?
>
> Patch
> in http://people.linaro.org/~hui.shi/MemBarRelease_Escape/MemBarEscape.patch
> <http://people.linaro.org/%7Ehui.shi/MemBarRelease_Escape/MemBarEscape.patch>
>
> __
>
> In hotspot, there are two different escape information recorded on a node.
>
> 1. AlllocateNode._is_non_escaping, true means allocation node’s escape
> state is noEscape.____
>
> 2. InitializeNode._does_not_escape, true means its allocation node’s
> escape state is noEscape or ArgEscape.____
>
> NoEscape has literal meaning. ArgEscape means allocation node is passed
> to callee but will not escape current thread. So ArgEscape is safe to
> remove MemBarRelase node for final field store in initialization method.____
Yes, the explanation looks reasonable to me. (Didn't know our escape
analyzer looks into static callees to figure out ArgEscape). I think
this is what EA intended its users to look for, when marking
InitializeNode-s:
if (n->is_Allocate()) {
// The object allocated by this Allocate node will never be
// seen by an other thread. Mark it so that when it is
// expanded no MemBarStoreStore is added.
InitializeNode* ini = n->as_Allocate()->initialization();
if (ini != NULL)
ini->set_does_not_escape();
}
Thanks,
-Aleksey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150908/4cea5847/signature.asc>
More information about the hotspot-compiler-dev
mailing list