4 ms·

"You can restore the past JIT-ed code from the cache and do new profile directed optimizations." Sure, but now you're paying for the compilation/runtime analys

by deong 12y ago

"You can restore the past JIT-ed code from the cache and do new profile directed optimizations." Sure, but now you're paying for the compilation/runtime analysis stage more than once. If the JIT compiler is actively doing any profiling of your code, that's time and watts being spent not running the program the user wanted you to run. In order for it to be a net gain, you have to improve the efficiency of the user's program enough through JIT to pay for this repeated cost of doing the analysis however often you do it. You can profile more intensively and more often, thus improving the generated code, but now you need to improve it a lot. Or you can profile lightly or infrequently, but now you have way less information with which to improve it. In practice, it seems to be very hard to do significantly better than just running it through a good compiler once.

rockdoe 12y ago
In practice, it seems to be very hard to do significantly better than just running it through a good compiler once. Why aren't the other Java runtimes doing it, then?
- deong 12y ago
  I can only guess, but I'd say it's a combination of factors. First, the JIT on my quad-core i7 can be pretty intense. I'm more willing to pay the overhead than I am on a device that has a tiny battery and gets hot in my pocket. So the JIT on my desktop is going to be better than the one on my phone. Second, Java is mostly a server language these days. The types of programs that run on servers are going to be more amenable to profile-guided optimizations than UI heavy event handling code that constitutes a large part of phone apps. And on desktops and servers, it just doesn't matter that much. Particularly on a server, startup time is pretty much irrelevant. So the downsides to JITs are minimized due to the nature of the workload.
- pjmlp 12y ago
  They are though. There are quite a few JVM with AOT compilers available.

by deong 12y ago

rockdoe 12y ago

In practice, it seems to be very hard to do significantly better than just running it through a good compiler once. Why aren't the other Java runtimes doing it, then?

deong 12y ago
I can only guess, but I'd say it's a combination of factors. First, the JIT on my quad-core i7 can be pretty intense. I'm more willing to pay the overhead than I am on a device that has a tiny battery and gets hot in my pocket. So the JIT on my desktop is going to be better than the one on my phone. Second, Java is mostly a server language these days. The types of programs that run on servers are going to be more amenable to profile-guided optimizations than UI heavy event handling code that constitutes a large part of phone apps. And on desktops and servers, it just doesn't matter that much. Particularly on a server, startup time is pretty much irrelevant. So the downsides to JITs are minimized due to the nature of the workload.
pjmlp 12y ago
They are though. There are quite a few JVM with AOT compilers available.