RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob

Roland Westrelin roland.westrelin at oracle.com
Mon Jan 21 02:59:03 PST 2013


One of the method has the following structure:

for ( .. ) {
  ..
  if ( ..) {
    ..
  } else {
    if ( .. ) {
      if ( .. ) {
        ..
      } else {
        if ( .. ) {
          ..
        } else {
          Math.pow(x, y);
        }
      }
    } else {
      if ( .. ) {
        ..
      } else {
        Math.pow(x, y);
      }
  }
  ..
}

Both Math.pow(x,y) have the same inputs and so a single PowDNode is kept and it's scheduled in the else of the outer most if. So the pow computation is executed independently of the other if conditions, more frequently and because the computation is expensive there's a noticeable performance regression. 

The fix consists in:

1) setting the control input of the expensive nodes (PowDNode, ExpDNode) to prevent IGVN to freely common nodes
2) During the loop optimization pass, consider each expensive node and, when possible, modify the control input to allow optimization by the IGVN while making sure it's not executed more frequently

http://cr.openjdk.java.net/~roland/7197327/

To test it, given it's quite rare to have 2 PowDNodes with the same inputs, I applied the same technique to a bunch of other nodes:

http://cr.openjdk.java.net/~roland/7197327/webrev.test/

Roland.


More information about the hotspot-compiler-dev mailing list