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

> You should expect a runtime that is used more on the server side to be "behind" when it comes to concerns that are more prevalent on the client

True, but the Client x Server concerns seem to be overlapping now, across the board. For instance, tech built for ChromeOS (a desktop class OS) is also used by GCP ("Container-optimized OS") and AWS ("Firecracker").

While ART has had tiered compilation (C1/C2 in the OpenJDK world) for quite a while. I also mentioned ART has long had Copying Collector (almost pauseless GC), which could help Server-grade apps just the same.

All that said, for ART, things are relatively "simpler" as it has to only target Linux+Fuschia on ARM32/64, x86/amd64, RISC-V ISAs.

An interesting side note about Dalvik/ART (Zygote) is that it uses the old Server-side technique of forking (but without exec; like httpd's "fork mode") to share pages and resources with its children (ie, with all app processes on Android).



> True, but the Client x Server concerns seem to be overlapping now, across the board.

Sure, which is why you're seeing this work.

> While ART has had tiered compilation (C1/C2 in the OpenJDK world) for quite a while. I also mentioned ART has long had Copying Collector (almost pauseless GC), which could help Server-grade apps just the same.

I hope you're not suggesting that ART has a similar quality of compiler optimisations and GC as the JDK. But if you are, you're welcome to try and run significant server workloads on ART and see how they compare to JDK 24.

BTW, the last (Go-style) non-copying collector was deprecated in the JDK in 2017 and completely removed in 2020: https://openjdk.org/jeps/363. The reason why the low-latency GCs (what you call "almost pauseless") aren't the default in the JDK is that minimising latency is not (yet?) the top requirement for server apps. Some value throughput more.




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

Search: