Conversation

It's amazing seeing that as expected, the dream of actual AOT for WebAssembly is already dead and (at least in the case of iOS) will stay dead for the near future if not indefinitely because the fantasy of AOT was never actually feasible
6
4
Replying to and
I wouldn't really say that they're moving away from it. Since Android 7 (Nougat), it uses a hybrid AOT / JIT compilation strategy in the default configuration. AOT compiled code for the bundled apps/libraries is shipped with the OS, and it starts with JIT for out-of-band updates.
1
2
For 3rd party apps, it also starts with JIT compilation. JIT compiler is set up to output persistent JIT profiles that are built up over time. When the device is plugged in + idle, it will regularly do profile guided AOT compilation for everything without bundled compiled code.
2
3
Since update installation occurs in the background due to the A/B update design, it will also recompile everything using PGO AOT compilation for system updates. This is just the default configuration though. It can be configured through system props and used in various ways.
1
1
Default: pm.dexopt.ab-ota: speed-profile pm.dexopt.bg-dexopt: speed-profile pm.dexopt.boot: verify pm.dexopt.first-boot: quicken pm.dexopt.inactive: verify pm.dexopt.install: speed-profile pm.dexopt.priv-apps-oob: false pm.dexopt.priv-apps-oob-list: ALL pm.dexopt.shared: speed
1
dalvik.vm.usejit: true dalvik.vm.usejitprofiles: true So, disabling the JIT and using full AOT compilation is still completely supported. Using 'speed' instead of 'speed-profile' removes reliance on JIT profiles. Using 'everything' avoids interpreter for one-time init code, etc.
1
The drawback is primarily using more storage space for third party app installations. A/B updates result in the recompilation on major upgrades happening in the background before the update installation is considered finished and it gets switched to the active OS partition set.
1
1