> Android and Firefox OS both also have a VM to run managed code, along with a JIT compiler. Android's VM, Dalvik, was specifically designed to be memory efficient in the case where several apps are running as separate Unix processes. Is the same true of SpiderMonkey?
Short answer: yes, SpiderMonkey has been designed to be quite memory efficient.
> But on top of this, Firefox OS and its apps add:
Actually, let me clarify something, if not for you, then for our readers: "on top of this" means essentially "on top of the kernel and HAL," rather than "on top of Android."
> [valid points] So how can you say that Firefox OS is more resource-efficient than Android? Perhaps the Android platform developers have gotten sloppy lately, since they're primarily concerned about high-end phones. But that can be remedied.
All your technical points are valid. However, you have not taken into account the fact that Android is much larger than that not to mention, conceptually, very old. Just the Core Libraries, for instance, offer at least three or four ways of reading/writing files. Most of these APIs should be removed for the sake of performance, as they were based on Java 1.0 designs from the 1990s, a time at which industry believed that disk speed would keep improving as fast as CPU speed and that concurrency was too expensive to be used. But these APIs cannot be removed, simply because too much code depends upon them, both in Android itself and in applications that Google would not want to lose. Sadly, this means that all such code is a performance hog, especially on mobile devices, since mobile storage is horribly slow in comparison to PC storage.
Now, while I am less familiar with the rest of the architecture of Android, I seem to remember this is true of many features and that many features are accidentally implemented several times in the kernel, Dalvik, the libraries and/or the frameworks, in the interest of (partial) compatibility with Posix, Linux, J2SE, etc – and tutorials.
While it would theoretically be possible to get rid of all these inter-layer duplications, and to only keep the good APIs, this effectively means breaking too much of both Android itself and of many applications. Google cannot afford to do that, as they would risk driving away all developers and users. Moreover, Google does not need to do that, as Android has always been targeted towards high-end phones. A new operating system, by opposition, with everything to win and nothing to lose, can start from a blank state. Moreover, since Firefox OS offers only high-level APIs and no NDK-style access, it is easier and will remain easier for a number of years, to perform whichever low-level refactorings are necessary to improve performance and/or memory efficiency without breaking applications.
Note that this is almost the reverse of Chrome vs. Firefox. Firefox is burdened by the number of add-ons that need to be supported, and the low-level APIs provided to these add-ons, while Chrome, starting with a blank slate and restricted public APIs, managed to rise the stakes of performance quite harshly.