JDK-6589834 : deoptimization problem with -XX:+DeoptimizeALot
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-08-06
  • Updated: 2014-07-03
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
With the internal testing option -XX:+DeoptimizeALot, running the SPECJVM98
test _213_javac fails with NullPointerException.  While this started occurring
with the 20070413103655.jrose.dolphin-intrinsics putback, it is actually an
existing incompatibility between the deoptimization support and the intrinsic
inlining of the server compiler.  The following program demonstrates the problem:

import java.util.Vector;
class deoptTest {

  Vector<Integer> _numbers;

  deoptTest(Vector<Integer> numbers) {
    _numbers = numbers;
  }

  void addElements(int start, int end) {
    for (int i = start; i < end; i++) {
      _numbers.add(Integer.valueOf(i));
      int sz = _numbers.size();
      if ((sz % 10000) == 0)
        System.out.println("+++ vector size = " + sz);
    }
  }

  static public void main(String args[]) {
    // create a Vector with an absurdly low initial size and capacity increment
    // to force constant reallocation
    Vector<Integer> numbers = new Vector<Integer>(100, 10);
    deoptTest dot = new deoptTest(numbers);

    for (int i = 0; i < 100; i++) {
      dot.addElements(0, 999);
    }
    for (int i = 0; i < 100; i++) {
      dot.addElements(0, 999);
    }
    for (int i = 0; i < 1000; i++) {
      dot.addElements(0, 999);
    }
    for (int i = 0; i < 1000; i++) {
      dot.addElements(0, 999);
    }
  }
}

When the fastdebug VM is run with the -XX:+DeoptimizeALot flag, it will fail with an
assertion that indicates that the interpreter stack is corrupted.  If the -XX:+VerifyStack
option is added, it will fail an assert at the deoptimization point.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9c6be3edf0dc
23-04-2009

EVALUATION The problem is that deoptimization does not expect to see an invoke bytecode in the top-most frame of the stack. If it happens, it does not properly handle the outgoing arguments to the method being invoked. This situation can occur from C2's intrinsic inlining. When doing the intrisinc inlining we set up the JVM state to the invocation of the method being inlined. In this case, the problem occurred at the allocation in the inlined code for Arrays.copyOf(). With DeoptimizeALot, a deoptimization is triggered on the slow path allocation path causing control to be transferred to the interpreter with an incorrect interpreter stack.
06-08-2007