I am trying to figure out the specific differences in the Dalvik and ART runtimes. I realize that ART no longer uses the Dalvik VM, however, one of the first things I noticed after installing the Android L preview was that the zygote process is still running. If they truly got rid of the Dalvik VM, wouldn't that render the zygote process useless? Furthermore, upon inspecting the source code released via AOSP, a large portion of Dalvik still remains.
2
-
1Hard to know, it's a developer release and FAR from complete. There's a lot of Kitkat / Jellybean stitched into it at the moment just to get it working and booting.– RossCJul 15, 2014 at 8:55
-
Being still a "developer preview", it might indeed make not much sense to speculate (though I follow Dan's explanation). It might be as Dan described, or it might be a "left over" not yet "fully obsoleted". When it still runs on L-Release, that's a different thing.– Izzy ♦Jul 17, 2014 at 14:40
Add a comment
|
1 Answer
Zygote isn't really bound up with Dalvik, it's just an init process. Zygote is the method Android uses to start apps. Rather than having to start each new process from scratch, loading the whole system and the Android framework afresh each time you want to start an app, it does that process once, and then stops at that point, before Zygote has done anything app-specific. Then, when you want to start an app, the Zygote process forks, and the child process continues where it left off, loading the app itself into the VM.
Although this method was originally designed for Dalvik, there's no reason ART shouldn't behave exactly the same way. It doesn't have to JIT-compile apps while they're running, but it still has a lot of app-independent Java stuff to load (i.e. the whole Android framework), so it makes sense to use the same fork-when-loaded method to start new processes.
It's natural on such a large project that there would be other left-overs from Dalvik that are still useful in a post-Dalvik world, so you shouldn't be surprised that there is other code that was originally written to be part of or to work with Dalvik, that is still around for ART to use.
answered Jul 15, 2014 at 11:02
-
Matches my understanding of Zygote (being a non-dev). From the "user view", it probably makes it easier to think of Zygote as "application server", acting as an "abstraction layer" between the apps and the OS (somehow like HAL does to abstract hardware): it doesn't matter what's "below" (Dalvik or ART), the interface deals with "stuff"?– Izzy ♦Jul 17, 2014 at 14:38
-
1It might make it easier to think of Zygote as an application server, but it's not a very accurate description. It's just the part of the OS that starts apps, and it's very much on the OS side of the app-OS boundary. Jul 17, 2014 at 16:30
-
Thanks, so at least my "basic understanding" was correct (I'm aware "application server" is not accurate, but easier to understand by a "normal user" – so let's make it "application service", to bring it further on the OS side ;)– Izzy ♦Jul 17, 2014 at 16:33
-
What exists in the source code are not "left-overs", and we are not at the post-Dalvik era! Dalvik bitcode is still the IR being used. Even with the highest setting, not everything is AOT-compilied, and there are still some stuff that need to be interpreted. So, for these, there is DalvikVM. Also, devices with low storage, will be using less AOT more interpretation. Lastly, zygote inits heaps of frequently used classes, which can save space as they can be shared between multiple applications. Sep 17, 2015 at 19:45
-
@Paschalis you are confusing JIT compiling with DalvikVM. Just because newer versions of the ART do JIT (just-in-time) compilation, doesn't mean Dalvik is still around. Oracle Java does JIT compilation as well, doesn't mean it uses Dalvik Jan 17, 2017 at 16:11