3 ms·
Startup time. JIT doesn't kick into action until after the app has started up and ran through some hot code paths. Up until that time things are interpreted and
by blinkingled 12y ago
Startup time. JIT doesn't kick into action until after the app has started up and ran through some hot code paths. Up until that time things are interpreted and thus slower.
Secondly there are limits to how much you can optimize at run time. For servers there is more leeway in terms of available memory and CPU power but on mobile you can only optimize so much without slowing things down with optimization and jit code generation overhead.
JIT generated code has to be generated every time the app runs. Besides the pages used to store the JIT code are process private - I.e. no sharing.
Compared to all of this - AOT can afford to optimize more, it only has to do it once, the framework code can be spit out to common shared files on the disk this enabling sharing of those pages and reducing memory consumption. This gives you speed, battery and memory benefits over JIT.
- rockdoe 12y agoUp until that time things are interpreted and thus slower. That's true - but not specific to mobile. For servers there is more leeway in terms of available memory and CPU power but on mobile you can only optimize so much without slowing things down with optimization and jit code generation overhead. Which makes me wonder why it's going into new versions of Android (running on 4 to 8 core devices, i.e. having plenty of free horsepower). If anything this is becoming less of an issue. JIT generated code has to be generated every time the app runs. False. The memory savings argument might be something - particularly with heavy use of system libraries. Android phones usually have relatively memory compared to their other resources.
- 51Cards 12y ago"Which makes me wonder why it's going into new versions of Android (running on 4 to 8 core devices, i.e. having plenty of free horsepower)." ... running on a very taxed battery.
- blinkingled 12y ago>>JIT generated code has to be generated every time the app runs. > False. How so? Do you know of production class JITs that cache generated native code and reuse it every time the process is re-executed?
- wmf 12y agoHotSpot? http://stackoverflow.com/questions/1992486/why-doesnt-the-jvm-cache-jit-compiled-code http://stackoverflow.com/questions/1992486/why-doesnt-the-jv...
- blinkingled 12y agoNope. I know for sure hotspot doesn't do it - neither for desktop nor for server. The "Oracle JIT" refers to the JIT that Oracle uses for Java code that executes inside of the Oracle database. Completely different environment and usage model. Read the first comment in your link to get a sense of why it isn't practical to do persistent code caching for a dynamic language like Java.
- teyc 12y ago+1 Battery life is the limiting factor in mobile phones. They are usually disconnected all day. It is worthwhile to put up with all the engineering pain because having a phone that runs all day is most to end users. Whenever I get a new phone, I'd have fun with it for about a week, and then turn off everything and try not to use it much so that I can still take and make calls by the end of the day.