[RFR] Remove MemBarRelease when final field's allocation is NoEscape or ArgEscape

Hui Shi hui.shi at linaro.org
Tue Sep 8 12:41:09 UTC 2015


Hi JIT members,


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



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.



Pasted test creates an Integer instance in foo, MemBarRelase node is
created at the end of initialization method as Integer's value field is
final. New instance is ArgEscaped because it is passed to bar (disable
inlining bar). It fails to remove MemBarRelase node now, because
AlllocateNode._is_non_escaping is used in MemBarNode::Ideal(PhaseGVN
*phase, bool can_reshape) and this flag is false.



public class TestInteger {

  public static void main(String[] args) {

     for(int i = 0; i < 1000000; i ++)

       foo(i);

  }



  static int foo(int i) {

    Integer newi = new Integer(i);

    return bar(newi);

  }



  static int bar(Integer i) {

    return i.intValue() + 2;

  }

}



This patch deletes MemBarRelease node when its allocation node is ArgEscape
or NoEscape by checking its InitializeNode._does_not_escape flag.


Regards

Shi Hui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150908/f2f46cf2/attachment.html>


More information about the hotspot-compiler-dev mailing list