4 ms·
A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into mem
by haberman 9y ago
A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image).
Java on the other builds its process image on the heap, using the executable file as input. Nothing is executed out of the binary file directly afaik. I believe classloading (defined in the Java spec) actually prohibits doing too much of this work ahead of time. The JVM has to defer work until startup in case the user wants to define a custom classloader.
My knowledge of the JVM is very basic compared to my knowledge of ELF, but I believe the basic gist of this is correct. I'm interested in diggging into this difference more deeply and writing a well-researched blog entry about it.
- chickenbane 9y agoI have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT. OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizations. So not only does Android perform the preloading optimization you mention for ELF but as the user continues to use their apps Android will continue to optimize the compiled binaries.
- haberman 9y agoGood to know. Does that mean Java classloaders are not supported on Android? And does this approach require breaking compatibility with that aspect of the Java spec?