Android 7.0 adds a just-in-time (JIT) compiler with code profiling to Android runtime (ART) that constantly improves the performance of Android apps as they run. The JIT compiler complements ART's current ahead-of-time (AOT) compiler and improves runtime performance, saves storage space, and speeds app updates and system updates.
The JIT compiler also improves upon the AOT compiler by avoiding system slowdown during automatic application updates or recompilation of applications during OTAs. This feature should require minimal device integration on the part of manufacturers.
JIT and AOT use the same compiler with an almost identical set of optimizations. The generated code might not be the same but it depends. JIT makes uses of runtime type information and can do better inlining. Also, with JIT we sometimes do OSR compilation (on stack replacement) which will again generate a bit different code.
JIT compilation works in this manner:
- The user runs the app, which then triggers ART to load the .dex file.
- If the .oat file (the AOT binary for the .dex file) is available, ART uses them directly. Note that .oat files are generated regularly. However, that does not imply they contain compiled code (AOT binary).
- If no .oat file is available, ART runs through either JIT or an interpreter to execute the .dex file. ART will always use the .oat files if available. Otherwise, it will use the APK and extract it in memory to get to the .dex incurring a big memory overhead (equal to the size of the dex files).
- JIT is enabled for any application that is not compiled according to the "speed" compilation filter (which says, compile as much as you can from the app).
- The JIT profile data is dumped to a file in a system directory. Only the application has access to the directory.
- The AOT compilation (dex2oat) daemon parses that file to drive its compilation.
The Google Play service is an example used by other apps. These application tend to behave more like shared libraries.
See the following high-level overview of how JIT works in the next diagram.
- Profiling information is stored in the code cache and subjected to garbage collection under memory pressure.
- As a result, there’s no guarantee the snapshot taken when the application is in the background will contain the complete data (i.e. everything that was JITed).
- There is no attempt to make sure we record everything as that will impact runtime performance.
- Methods can be in three different states:
- interpreted (dex code)
- JIT compiled
- AOT compiled
- If both, JIT and AOT code exists (e.g. due to repeated de-optimizations), the JITed code will be preferred.
- The memory requirement to run JIT without impacting foreground app performance depends upon the app in question. Large apps will require more memory than small apps. In general, big apps stabilize around 4 MB.
Turn on JIT logging
adb shell stop
adb shell setprop dalvik.vm.extra-opts -verbose:jit
adb shell start
adb shell stop
adb shell setprop dalvik.vm.usejit false
adb shell start
Force compilation of a specific package
$ adb shell cmd package compile for usage. A few common use cases:
adb shell cmd package compile -m speed-profile -f my-package
adb shell cmd package compile -m speed -f my-package
Force compilation of all packages
adb shell cmd package compile -m speed-profile -f -a
adb shell cmd package compile -m speed -f -a
Clear profile data and remove compiled code
- One package:
adb shell cmd package compile --reset my-package
- All packages
adb shell cmd package compile --reset -a