kinda wish I could add a second compilation stage but at runtime, like ok now I have the environment present, configs, etc - let's recompile given that new info
Conversation
Replying to
I'm too much into the Unix philosophy or small parts that do the job well, as Java is designed entirely around the one big app that runs for a long time to make JIT and other tricks like that effective.
Too many Java people tried to push it for small projects/programs.
2
I've never explored Java enough because of it's limitations to understand how good/bad the JVM is.
Though I did learn enough about it to not like the language, but did learn to appreciate the backwards compilability (write on a newer language, but run on an older implementation)
1
OpenJDK isn't the only approach to implementing it. twitter.com/DanielMicay/st is significantly more broadly deployed at this point anyway. The nicest way to use the Java ecosystem is Kotlin and Kotlin has been Android's default language for apps rather than Java for a while now.
Quote Tweet
Replying to @erincandescent @rustonaut and 2 others
OpenJDK design choices are very focused on long running server applications. Design choices for the Android Runtime are far different. Has equally modern concurrent compacting GC with a focus on latency for apps in foreground and memory usage in the background, not throughput.
Android essentially does what said: compilation to dex by devs and devices do profile-guided AOT compilation specialized for SoC. Baseline profiles are provided by libraries / app. App store can gather/provide more like Play Store does. JIT generates them on device.
1
1
Android's JIT is essentially a limited in-memory caching variant of the AOT compiler for hot code which largely exists to produce profiles for AOT compilation. Results in you getting AOT compilation specific to your actual usage based on which portions of the program you use.
1
1
Show replies