RFR: 8253101: Clean up CallStaticJavaNode EA flags

[Liu, Xin]

Vladimir, 

Actually, what you observe in JDK-8012974 doesn't limit to boxing objects.  A non-escaping substring has very similar property.  C2 can replace its field value: byte[] with its parent's value + offset.  Maybe we can avoid from allocation and arraycopy in this way. 
More generally, all JavaCall nodes which return an OOP deserve to be parsed in EA(and inlined after EA).  If an oop is non-escaped, any of its field may be potentially replaced by the equivalence values found in current CU, isn't it? 
What do you think about this direction? We have some experiments based on substrings. We would like to make this optimization as general as possible. 
Back to this PR, I think we can take it off this time because we can't finish the feature before jdk16.  Another reason is CallStaticJava seems not the ideal Call to store such information. If we need to add it back, I think we can create a dedicated subclass of JavaCall for the general case. 

What do you think?
Thanks,
--lx



On 10/27/20, 10:38 PM, "hotspot-compiler-dev on behalf of Vladimir Kozlov" <hotspot-compiler-dev-retn at openjdk.java.net on behalf of kvn at openjdk.java.net> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On Wed, 28 Oct 2020 02:16:43 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

    > Please review this small change to cleanup fields: _is_scalar_replaceable and _is_non_escaping from CallStaticJavaNode as well as code which assigns to those fields.
    >
    > The change was tested with run-test-tier[1-3] on Linux arm64 and x86-64.
    >
    > Thanks,
    > Jason

    The idea was to delay inlining of valueOf() after EA:
    https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-May/010422.html

    -------------

    PR: https://git.openjdk.java.net/jdk/pull/889