RFR(S): 8069191: moving predicate out of loops may cause array accesses to bypass null check (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Mar 17 18:14:56 UTC 2015

This is what I waited for long time! Thank you for doing this, Roland.

How you handle case when CastPP is input of Phi node?

I am worried how you separate cases when precedence edge added from CastPP and other precedence cases. Can you explain? May be there are no problems.

Thanks, Vladimir

On 3/17/15 3:54 AM, Roland Westrelin wrote:

http://cr.openjdk.java.net/~roland/8069191/webrev.00/

In the test (that needs to be run with StressGCM to cause incorrect code generation), a dependency carried by a CastPP is lost when CastPPs are removed after CCP. Detailed description of the bug is in: https://bugs.openjdk.java.net/browse/JDK-8069191 Vladimir suggested investigating the performance impact of keeping the CastPPs for the entire compilation. I found that this still causes performance regressions as documented in: https://bugs.openjdk.java.net/browse/JDK-8039999 The fix I suggest is to keep CastPPs during optimizations and remove then during final graph reshaping. To not loose the dependencies they carry, precedence edges are added to memory operations that depend on them. During GCM, the control of the memory operations to take the current control and the precedence edges. Experiments show that this scheme doesn’t cause performance regressions (I ran promotion testing on x64 and sparc). Roland.

More information about the hotspot-compiler-dev mailing list