This article http://www-128.ibm.com/developerworks/library/j-jtp12214/ has an entire section on dead-code elimination (DCE).

Does anyone know what all the criteria are by which the hotspot JIT compiler can determine that code is "dead"?

One obvious criteria is if the code will never get executed. I think that the canonical example is code like this:

static final boolean debug = false;
       static void someMethod() {
               if (debug) {
                       ...
               }
       }

Here, the compiler (javac as well as hotspot's JIT) can determine that someMethod has nothing inside it that could ever get executed, so it can be turned into an empty method.

If you look at that developerworks link above, he gives an even more interesting example for how hotspot's JIT can make sophisticated DCE based on inlining.

What I want to know is what are all the criteria that hotspot can use to decide that code is dead. Code that is never executed is always correct. But can it make more liberal decisions as to what counts as dead code?

Consider this code:

int[] foo = new int[1000];
	int bar = foo.length;
	// don't use foo again, but do use bar

A smart compiler could recognize that the array declaration and allocation is actually useless, and simply do

int bar = 1000;

(Thank you Brian for this example.)

 

 

What are the rules? Naturally, the only definitive answer can be given can be given by the HotSpot JIT.

That's not a very satifying answer, but it's true. The server JIT, like most compilers, has been taught hundreds and hundreds simplifying transformations that, in part, enable dead code elimination. Enumerating the criteria is a nearly impossible task.

But, your specific example is an interesting case.

int[] foo = new int[1000];
int bar = foo.length;

For simplicity, I assume foo and bar are locals to a method, and in this case, the 6.0 HotSpot Server JIT will recognize that foo is unchanged before the initialization of bar, and effectively change it to:

int[] foo = new int[1000]; 
int bar = 1000;

The JIT can't get rid of the allocation of the new array without a more advanced optimization called Escape Analysis, which attempts to determine the dynamic scope of objects. Of course, if these two lines comprise the whole method, then the analysis is fairly trivial.

Any intervening code will make the analysis more complex:

int[] foo = new int[1000]; 
baz(foo); 
int bar = foo.length;
qux(foo);

The calls sites will preclude your desired optimization, unless the called methods baz and qux can be inlined and analyzed. The code in baz can neither modify foo nor allow it to escape, and qux can not allow it to escape.

HotSpot's implementation of escape analysis is not quite yet complete, but should be available relatively soon.