4 ms·
You seem to be knowledgeable about the Android situation - what’s the current deal? From what I gathered, android uses a hybrid runtime that has many parts of t
by kaba0 4y ago
You seem to be knowledgeable about the Android situation - what’s the current deal? From what I gathered, android uses a hybrid runtime that has many parts of the code AOT compiled and cached, but can JIT compile as well to suit for a particular device, is my understanding correct?
But yeah, I agree with you, they really should have gone with possibly a simpler JIT compiler and an alternative GC implementation that is more conservative in memory usage.
- saagarjha 4y agoWhat's wrong with the current one?
- pjmlp 4y agoHere for the JIT/AOT, since Android 7 (5 and 6 used AOT only), https://source.android.com/docs/core/runtime/jit-compiler?hl=en https://source.android.com/docs/core/runtime/jit-compiler?hl... The issue isn't even converting JVM bytecodes into DEX, other compliant Java implementations for embedded do similar approaches, see PTC and Aicas. The issue is how they have stagnated Java support on purpose as means to push Kotlin, they aren't being innocent by using Java 8 samples against Kotlin features. And the whole but Oracle doesn't cut it, given how dependent Kotlin is on the whole JVM ecosystem.
- _old_dude_ 4y agoIt starts that way, with a mark and sweep collector (think Java CMS or the GC of Go). But some applications like games or Facebook are monsters so the GC was changed to a copy collector which has a better throughput, avoid fragmentation at the cost of using more memory. Also the code is not just AOTed, Android is using profile guided AOT. After several days of usage, the code is AOTed with the profile collected from previous runs.