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.
Conversation
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.
1
2
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
There's some information at source.android.com/devices/tech/d but I'm not sure how up-to-date it is on the technical details. In Android Q, they've also added GC integration with mallinfo for it to estimate the native allocations tied to GC allocations and how much is actually being freed.
1
1
Here's that Android Q change:
android.googlesource.com/platform/art/+
android.googlesource.com/platform/art/+
I'll need to deal with this in github.com/GrapheneOS/har since I need to implement a real mallinfo instead of stubbing it out. Similar to how I need to name regions for the memory profiling tools.