3 ms·

> but we’re performing the wasm to native code translation ahead of time, when Firefox itself is built. This might be an advantage for startup performance, but

by est31 7y ago

> but we’re performing the wasm to native code translation ahead of time, when Firefox itself is built. This might be an advantage for startup performance, but it's also a disadvantage performance wise as then you can't use all available features of the CPU. That's one of the advantages that wasm gives you. > we were often asked, “why do you even need this step? You could distribute the wasm code and compile it on-the-fly on the user’s machine when Firefox starts.” We could have done that, but that method requires the wasm code to be freshly compiled for every sandbox instance. Per-sandbox compiled code is unnecessary duplication in a world where every origin resides in a separate process. Android keeps an on-disk cache, performing native compilation at installation time, or at first startup after an OS update. One could have a similar cache for Firefox as well. Anyways, this stuff can be improved in the future as well. This doesn't change the fact a bit that it's an amazing and really great idea to improve safety of the browser. I love it!

pjmlp 7y ago
That is the same approach used by the language environments on mainframes, Windows Store (MSIL cloud compiler), watchOS and a couple of other platforms, I would guess.
- deleted 7y ago
  [deleted]
chrismorgan 7y ago
> Android keeps an on-disk cache, performing native compilation at installation time, or at first startup after an OS update. If you’re describing what I think you’re describing, that was a Dalvik thing (Android 4.4 and earlier), which ART (Android 5 onwards) doesn’t do. I also found it a pain, because from time to time even when there hadn’t been an OS update or any other such change my phone would take three or four minutes longer to boot up as it decided it had to optimise all its packages. No idea whether that was a typical experience.
- est31 7y ago
  The compile target of ART's dex2oat tool is actually native ELF code while Dalvik's dex2opt only created odex files, so the on-disk cache still exists. I've found sources that this is still done on app installation. On whether it's still done on OS updates, I couldn't find sources, but I guess your experiences mean that now OS updates don't trigger recompilations any more. Thanks for the pointer!
  - yzmtf2008 7y ago
    It still happens, except now the recompilation is done before the reboot for the upgrade, so that it doesn't create a massive downtime for upgrades. But if you manually upgrade, you can still see one (very long) step called "Optimizing Apps".
  - pjmlp 7y ago
    Here is the complete workflow post Android 7. https://source.android.com/devices/tech/dalvik/jit-compiler https://source.android.com/devices/tech/dalvik/jit-compiler
GrayShade 7y ago
The Firefox bytecode cache is pretty similar. I think it's regenerated after updates.
cogman10 7y ago
Ditto on the love! This is such a good and almost a "oh, duh" moment. They can significantly decrease the attack surface simply by aggressively sandboxing everything. The fact that it may even be faster due to the possibility to JIT in platform specific optimizations is really gravy.

by est31 7y ago

pjmlp 7y ago

That is the same approach used by the language environments on mainframes, Windows Store (MSIL cloud compiler), watchOS and a couple of other platforms, I would guess.

deleted 7y ago
[deleted]

chrismorgan 7y ago

> Android keeps an on-disk cache, performing native compilation at installation time, or at first startup after an OS update. If you’re describing what I think you’re describing, that was a Dalvik thing (Android 4.4 and earlier), which ART (Android 5 onwards) doesn’t do. I also found it a pain, because from time to time even when there hadn’t been an OS update or any other such change my phone would take three or four minutes longer to boot up as it decided it had to optimise all its packages. No idea whether that was a typical experience.

est31 7y ago
The compile target of ART's dex2oat tool is actually native ELF code while Dalvik's dex2opt only created odex files, so the on-disk cache still exists. I've found sources that this is still done on app installation. On whether it's still done on OS updates, I couldn't find sources, but I guess your experiences mean that now OS updates don't trigger recompilations any more. Thanks for the pointer!
- yzmtf2008 7y ago
  It still happens, except now the recompilation is done before the reboot for the upgrade, so that it doesn't create a massive downtime for upgrades. But if you manually upgrade, you can still see one (very long) step called "Optimizing Apps".
- pjmlp 7y ago
  Here is the complete workflow post Android 7. https://source.android.com/devices/tech/dalvik/jit-compiler https://source.android.com/devices/tech/dalvik/jit-compiler

GrayShade 7y ago

The Firefox bytecode cache is pretty similar. I think it's regenerated after updates.

cogman10 7y ago

Ditto on the love! This is such a good and almost a "oh, duh" moment. They can significantly decrease the attack surface simply by aggressively sandboxing everything. The fact that it may even be faster due to the possibility to JIT in platform specific optimizations is really gravy.