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.
Posted Date : 2007-08-06 23:59:33.0

N/A

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.
Posted Date : 2007-08-06 23:59:34.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9c6be3edf0dc
Posted Date : 2009-04-23 23:43:09.0