[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


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

    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)


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