If bytecodes whose default successor is a backward branch will have bad debug information for the goto. If you compile only java/util/zip/InflaterOutputStream.read you can see the debug info for bytecode 92, ifeq has an empty stack in some cases.

The problem is that do_If uses goto_default_successor which makes the unconditional branch into a safepoint but it uses the block->end()->state() for the debug information. This is wrong since deoptimization at an if expects a value on the top of the expression stack, so it should be using state_before. Actually it doesn't need to be a safepoint at all so one fix is to only create a safepoint for gotos. This brings up another problem, which is that we can convert a if bytecode with constant arguments into a goto but this will produce debug information from block->end()->state() instead of from the state_before of ths if instruction. The following piece of code illustrates both problems.

public class ifeq implements Runnable {
  public void run() {
    //for (int i = 0; i < 50; i++) {
    while (true) {
      try {
        System.gc();
        Thread.sleep(50);
      } catch (Exception e) {
      }
    }
// System.exit(0);
  }

  public static void main(String[] args) {
    Thread t = new Thread(new ifeq());
    t.start();
    ifeq();
    constant_if();
  }

  public static void ifeq() {
    int count = 100000;
    int r = 0;
    try {
      while (r == 0) {
        double d = 2394829834.0;
        double d2 = d;
        count--;
        if (count == 0) {
          return;
        }
      }
      return;
    } catch (Exception e) {
    }
  }

  public static int zero() { return 0; }

  public static void constant_if() {
    while (zero() == 0) {
    }
  }
}


The constant_if case will crash with "too many pops" if run with DeoptimizeALot under runThese. The ifeq case is much harder to see in practice but in both cases if you print of the debug information for the nmethod you can see the problem.
thomas.rodriguez@eng 2001-06-29