[kbenson]

> In theory Java can be more optimized than C—machine code generation benefits from knowledge of how the program actually executes.

I used to believe this, but I think the same level of theory that says a JIT can be sufficiently smart enough to figure everything out means that a compiler can be sufficiently smart enough to figure everything out as well. This is one of those areas that theory and practice are so far apart that theory should be accompanied with a context of "some day, in the future, if we're lucky..."

What we've seen in reality is that as JIT engines get better, compilers also get better, and retain their lead.

[LnxPrgr3]

This is true. Compilers even sometimes act vaguely like JIT—see also speculative devirtualization. If your code really needs runtime profiling information to optimize well, we have profile-guided optimization too.

In theory your could still benefit from JIT if, say, you have a Java application that's half written in XML config files and always heavily customized for each deployment. But probably that application also needs 8 modern cores and 16GB RAM to start for reasons that aren't even Java's fault.

But I try not to write code like that.

[computerphage]

No, even in theory there's an advantage to having information only available at runtime. Some optimizations depend on the probability distribution of data coming in (eg. an optimization for a CSV parser that makes it faster when dealing with well-formed CSVs that would slow the program down if it starts getting a lot of mis-formatted CSVs). The compiler can choose one or the other, but not both. The JVM can effectively choose both by deciding during execution.

If the compiler is allowed to embed a JIT or other runtime system, then all bets are off.