United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6589834 deoptimization problem with -XX:+DeoptimizeALot
6589834 : deoptimization problem with -XX:+DeoptimizeALot

Details
Type:
Bug
Submit Date:
2007-08-06
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs16

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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
                                     
2009-04-23
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.
                                     
2007-08-06



Hardware and Software, Engineered to Work Together