That sounds a lot like what Darwin does with the shared cache, to prelink the system dylibs into one image, pre-bind ObjC and Swift runtime data structures, etc., though we're starting from already native code
Conversation
The shared RELRO thing is for native libraries / executables, specifically Chromium, since the library gets mapped in all of the Chromium renderer sandbox processes which are also spawned for every app using the WebView. There's actually a separate WebView sandbox Zygote now.
1
I have to drop most of this in order to have proper per-app ASLR and other probabilistic mitigations rather than shared bases and other secrets. It makes a big difference for app spawning time and also memory usage, since a lot of the initial heap in the Zygote remains the same.
1
Can see some of how they take advantage of the Zygote here: android.googlesource.com/platform/frame. This is run a single time on boot for each supported architecture.
The image classes section in source.android.com/devices/tech/d explains that bit. For their use it only really optimizes Zygote start-up.
1
In my past work, which I still need to port forward, I just disabled all of this and used on-demand loading. It definitely makes a noticeable difference though. There's a 200-300ms or so delay like launching a desktop app instead of everything launching in a couple frames.
1
The JIT compiler is also way different than something like the Java runtime JIT compiler for reasons tied to that too. GC is also a lot different, with priorities a lot more like the Go GC. I'm sure people using Java for desktop apps would love to have a desktop version of ART.
1
1
They tried to use LLVM for AOT compilation and maybe even JIT compilation at one point. It never shipped. They have a homegrown optimizing compiler instead: android.googlesource.com/platform/art/+. So it goes Java bytecode -> dex -> odex (what is shipped) -> { interpreter, SSA IR -> native }.
1
1
It's really so much better having the specialized compilation stack, despite it lacking so much of the optimization work in LLVM. If you don't care about compilation time, you can use higher level IR over LLVM, but if you JIT, compile-time matters a lot even with many layers.
1
1
It's obviously a nice ideal to have the enormous amount of work shared between languages, but it really breaks down with JIT. I think the WebKit move to LLVM and then away from it is very telling. LLVM just takes way too long and takes too many resources (hurting battery life).
1
Thank you for laying this out. Funny that ART's an open-source system used by so many folks but not many folks (including me) know much about how it works. This makes me curious about the details of the GC.
1
1
Well you could skim over android.googlesource.com/platform/art/+. There are a few different kinds of heaps and garbage collectors. It's also worth noting that on 64-bit, ART currently still prefers to use a 32-bit GC heap. It puts everything at a random 32-bit base in lower 4G of address space.
So that it can use 32-bit pointers for all the Java pointers, including the stuff internal to the runtime. It's one of the things that I had to address before, along with some other complications tied to them generating boot.art heap images for each base library.
1
1
It uses different garbage collectors for apps in the foreground (including foreground services) and background. The heaps are also split up into different kinds of allocators. These headers show that to some extent without details:
android.googlesource.com/platform/art/+
android.googlesource.com/platform/art/+
1
Show replies