Unexpected GC Behavior

[Dan Chisholm]

Here's something interesting. It appears that the compiler does some unexpected optimizations that become apparent when the finalizer method announces the finalization of each instance. The following code example behaves as expected. The first four instances of class J are finalized but the last instance is not finalized. The output of the program is 0123 and then the wait method waits forever because the last instance is not finalized and the J.notFinalized method never returns zero.
As long as the local variable j in method m1 is initialized to null before the "for" loop is entered then the scope of variable j remains the entire body of method m1. However, the compiler appears to have the option to reduce the scope of variable j.
If j is not initialized before the loop and if j is not used after the loop then the scope of j is reduced to only the body of the loop. After control passes out of the loop then any object referenced by j is eligible for finalization and garbage collection. As a result, all five instances of class J become eligible for garbage collection when the loop is completed and all five instances are finalized and method m1 returns and the program runs to completion. The output is 01234.
Is this behavior well known or was I the only one that did not realize that optimization can reduce the scope of a local variable?

class J {
  private static int notFinalized;
  public static int notFinalized() {return notFinalized;}
  private K k = null;
  private int name;
  public int name() {return name;}
  public J(K k, int i) {this.k = k; name = i; notFinalized++;}
  public void finalize() {
    synchronized (k) {
      System.out.print(name);
      notFinalized--;
      k.notify();
    }
  }
}
class K {
  private void m1() {
    J j = null;
    for (int i = 0; i < 5; i++) {
      j = new J(this, i);
    }
    Runtime.getRuntime().gc();
    synchronized (this) {
      while (J.notFinalized() > 0) {
        try {wait();} catch (InterruptedException ie) {}
      }
}
  }
  public static void main(String[] args) {
    new K().m1();
  }
}

Go ahead and run this code example. The output should be 0123 before the program waits forever for the last instance to be finalized. Then run the program again with the initialization of j removed. The scope of j will then be reduced to the body of the loop and all five instances of j will be finalized.
It is important to remember that the real exam only tests behavior that is defined in the JLS. Undefined optimizations are not required knowledge. At this point, I'm not suggesting that this behavior is required knowledge. I just think it's interesting.
[ October 20, 2002: Message edited by: Dan Chisholm ]

[William Brogden]

I think I ran into the same thing with one of the mock questions I wrote. I thought that as long as the variable was in scope, it would not be GCed, in spite of the fact that execution could not possibly return to the code using the variable. Somebody objected to it so we tried some experiments.
As I recall, the JDK 1.0 level compiler/runtime would not GC as long as the thread was in the method but later versions apparently could recognize that the variable could be GCed. A big surprise to me.
Bill