Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks, I didn't know that, definitely a huge TIL.

Also, Android went from Dalvik to ART right? Those are both still VMs? Latest android looks like ART + JIT, but you can't AOT a JIT (that's the whole point of doing it Just In Time)?

Maybe I should take a look at Java 9/10, but if an employer isn't requiring it, and library support is somewhere near similar, I'm definitely considering doing the project in Rust first, then Clojure, then Frege, then Java 9/10.

Outside of the insane wealth of libraries that exist as a result of no one really having a good cross-platform choice for the last few decades, I don't think I'd choose plain Java for a project today. The JVM, maybe, but not plain Java on top of it. Luckily, I'm not the only developer out there, since there are tons of people who love java are still supporting it and using it, making cool things with it, and pushing it to be better.



Android is a bit more complex than that.

Until version 5.0, there was only Dalvik, a register based VM with a very basic JIT compiler.

On version 4.4, ART was introduced, but you had to explicitly enable it and many OEMs did not had it available anyway.

ART was a pure AOT compiler, at installation time on-device.

Given that it was taken hours to recompile everything when updates came on phones with lots of apps, Android 7 introduced a multi-mode interpreter/JIT/AOT toolchain.

On 7 and later, when an application starts for the first time, the interpreter written in hand optimized Assembly is executed, then control is given to the JIT, which in turn makes use of PGO.

A background AOT compiler takes the PGO data generated by the JIT and creates an optimized AOT binary for the application.

The next time an application is executed, the AOT compiled binary is used, until there is some kind of change, like an update or unexpected execution path, that requires a recompilation to take place.


> Those are both still VMs? Latest android looks like ART + JIT, but you can't AOT a JIT (that's the whole point of doing it Just In Time)?

Dalvik was a JIT VM. Then, for Android 5.0 (Lollipop), Android moved to AOT compile code (On installation and ROM upgrade, which is why if you ever updated Android then, you'd be sitting and waiting for a few minutes while Android optimized apps).

Then recently (I don't remember if it was for Marshmallow or Nougat) Android went back to a JIT VM on install, followed by a background AOT compile. This way installation goes faster (it doesn't have to compile everything right away), ROM upgrades go way faster (you don't have to AOT compile tens to hundreds of apps before being able to use your phone), and Android can do guided optimization during AOT (it knows which hot-paths were taken).


You can see here:

http://openjdk.java.net/jeps/295

Basically Java AOT is half-assed solution like so many other Java solutions e.g Java GUIs, Java build tools, Java generics etc etc.


Sure, because fully thought out solutions like Python 3 do wonders to keep the community united.

Either one replaces the engines in mid-flight, or parks the plane with perfect thought out solution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: