[8u20, 9] RFR(S): 8011646 : SEGV in compiled code with loop predication

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed May 28 19:45:54 UTC 2014

Good. Thank you, Albert.


On 5/28/14 12:16 PM, Albert wrote:
> Hi,
> could I get reviews for this small patch?
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8011646
> Problem:
> LibraryCallKit::inline_native_hashcode() uses a control input to the
> load node 'n' that loads the header.
> 'n' is connected to a castPP node, which maintains the dependency
> between the null check of 'n' and 'n'.
> A later compiler phase removes this castPP. The dependency between the
> null check and 'n' is lost if
> the 'n' has a control input (see MemNode::Ideal_common_DU_postCCP() ).
> The reason for the
> lost dependency is that loop predication erroneously sets the control
> edge of the load to a predicate
> that is hoisted out of the loop.
> If, however, the load has no control edge,
> MemNode::Ideal_common_DU_postCCP() sets the control edge
> correctly. This
> The bug description contains a Java program that reproduces this
> behavior. Also, the bug description contains
> a graph that can be viewed with the IGV. For example, the LoadL node
> (830) in Phase "After Parsing" has a
> control edge that is connected to node 780. At the phase, the graph is
> still correct. In phase "InterGVN 2"
> the control edge is connected to a node outside the loop. As a result,
> the dependency between the null
> check and the load is lost.
> Solution:
> Do not add a control input to the load. As a result, the control to the
> load is set correctly when the castPP node
> is removed.
> Webrev:
> http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
> Testing:
> Failing test case, regression test, jprt
> Many thanks to Roland and Vladimir who helped me a lot with this bug.
> Best,
> Albert

More information about the hotspot-compiler-dev mailing list