3 ms·

This multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be b

This multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be beneficial, but 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.

jdmichal 11y ago
> ... 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.
richard_todd 11y ago
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.
sievebrain 11y ago
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).
- iconhacker 10y ago
  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.

jdmichal 11y ago

> ... 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.

richard_todd 11y ago

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.

sievebrain 11y ago

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).

iconhacker 10y ago
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.