@Radu:
You should read the links "the idiots" (someone gave this name, vi_?) have written and where they try to explain why JIT-interpreted code can and eventually will probably be faster than fully compiled code (typically in applications which use OOP).

What you are saying is not wrong, but you are not looking the big picture. There is extra information available in running time. Only VM-type of solutions can use this running-time profiling information for optimizations. The efficiency gain in OOP-type of programs can easily be more than the loss which come from the JIT and having a code in a bytecode form in the beginning.

You cannot get all this "extra information" by running test cases and profiling few sessions. In a long running applications the situation is dynamic and depends often on undeterministic inputs the program gets from the outside world. Think www-browser which have easily millions of dynamic objects which have different life spans.

One of the reasons why Firefox slows down and "leaks" memory, which you notice after several days heavy use, is because it has been coded with C++ and it cannot use this extra running time information for optimization. It would be a useful and interesting experiment to port Firefox to use Java. Already Firefox uses XUL and Javascript (interpreted languages), which helps the situation.

The clever JIT will never throw away the used bytecode which it knows will be run many times, because in latter time some other compilation of the bytecode may become more faster when enough runtime information is gathered.

http://portal.acm.org/citation.cfm?id=345105.352548