> ... for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.

Isn't this statement pretty much the entirety of the reason to implement multi-tiered JITs? Do a fast JIT with few optimizations to get out of interpreted mode. Then do a slow JIT after you've collected enough statistics to make good optimization decisions.

To me that's like saying compression algorithms don't necessarily make data smaller. It's true enough, but you can still make general comparisons between approaches.

If your work has an "inner-loop" situation, then the JVM can optimize the heck out of it using statistics specific to this particular execution. That's huge.. it opens up all kinds of concrete optimizations that aren't possible with static analysis alone (precomputing call targets, knowing what to inline, etc.). I'd wager this is a major factor in cases when the JVM occasionally outperforms C.

But no, it doesn't necessarily help.

Actual gathered statistics say you're wrong. Profile guided optimisations can easily add 20% performance or more. And for that to work, the easiest path for the developer is a tiered JIT. More concretely, you can disable the tiered JIT on the JVM and find out what it buys you (and there are people who have done this).

The fact is that before the JVM has a chance to optimize the code, the app already restarted by the user unless it is some long running server process. On the server side, JVM is so heavy, normally there is only 1-2 heavy JVM running for web server and database driver on the entire machine. On the client side, Java is a joke. Though users now have more choices: Swing, AWT, JavaFx. Every one of these is hard to use comparing with C# or Qt. Most native platform developers hate Java, including OSX developers.