Hacker News Reader

Comment by ignoramous | Hacker News Reader

> While start-up times don't matter that much for long running workloads, they can make a huge difference in cloud-native scenarios where applications are dynamically scaled out, spinning up new instances on demand as the load of incoming requests increases.

"App Images" are what these are called in Android afaik. ART (the Android Run Time) has been capable of "AoT Class Loading & Linking" since 2016/7 (and ~pauseless GC since 2019). Seems like the desktop/server grade JVMs have a lot of ground to cover.

View on HN

Both the requirements and the workload challenges of server-side applications differ greatly from client applications. The JDK has had a pauseless GC (i.e. <1ms pauses) for 18 months now. The need for fast startup and warmup in server-side apps is newer than for client apps, and even with it, optimising for peak performance is still a higher priority than for client apps.

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 and vice-versa, and that's exactly what you see.

I was configuring Shenandoah GC on OpenJDK 8 before COVID, so I can say for sure that it's been available for a lot longer than 18 months. However, ZGC (the other low-pause-time collector) has only been the default for a little while.

Please don't write pauseless if there are short pauses. Pauseless in the Java GC context is a marketing scam.

We call them low-latency GCs, but I was responding to a comment that called the same thing "pausless". However, even programs without any GC pauses can have pauses of a similar duration due to OS activity, so programs on regular OS aren't generally pauseless anyway and the term is mostly meaningless in most contexts. As a marketing term (which we don't use) it merely means the application won't experience GC-related pauses that are longer than OS-related pauses.

This is some weird way of counting. A system pause plus a GC pause is two pauses. Just because one pause can't be avoided doesn't mean you can introduce more pauses.

Just to be clear, the pause in ZGC is done as an optimisation of thread synchronisation (there's no GC work done in the pause). It's just as easy to do things without anything you would consider a pause, only it's less efficient. Momentarily stopping all program threads is just an efficient way to deliver a message to all threads considering that the OS might have some threads descheduled.

At the end of the day, we care about the latency for some particular thread(s), and truly minimising that at this level requires a realtime kernel (that comes with significant performance disadvantages).

> I was responding to a comment that called the same thing "pausless"

In my defense, I called it "~pauseless" (as in, roughly pauseless).

Pebal is really pedantic about the term in every thread. Because apparently only he has ever achieved pause free GC for his C++ gc.

Unless you are on a realtime OS, you may see longer pauses from the OS due to scheduling other processes, so I think it's fair to consider the new low-latency collectors (Shenandoah, ZGC) pauseless from a practical point of view.

You can't call GC pauseless if it introduces pauses. We don't say something is free if you have to pay little for it. We say it's cheap.

I think as a technical term, pausless (as used here) has a specific meaning, just like real-time has a specific technical meaning (not literally 0 latency since that's generally physically impossible).

> 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.

On the contrary, lots of this work was already present in commercial products long before Android came to be,

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/products-services/jamaicavm/

https://eclipse.dev/openj9/docs/aot/

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=refe...

Now gone, https://en.wikipedia.org/wiki/Excelsior_JET

What you are getting now is commercial work being offered as free beer, also why Excelsior JET is no longer relevant as company.

Thanks.

> On the contrary, lots of this work was already present in commercial products

I should have been clearer that I meant other OSS JVMs have catching up to do.

> long before Android

True. The evolution of Dalvik/ART remind me of HP Dynamo: https://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-2...

> What you are getting now is commercial work being offered as free beer

... AOSP is free as in beer.

> AOSP is free as in beer.

True, however it isn't Java proper, and apparently Google has started to rewrite subsystems in Kotlin as well, when initially they said the OS layers would still be Java (language).

Apparently the updates to Java 11 and 17 LTS subsets in ART, were motivated to keep up with Maven Central more than anything else.

Java has had AOT via GCJ or some commercial compiler which starts with a E and not Eclipse but I cant remember its name, since early 00s. The Android Run Time only supports a specific version of the JDK and a subset of its available Java APIs so having official AOT support is an entirely different story. And that is not even mentioning Graal AOT.

Reply on news.ycombinator.com