4 ms·

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

by pron 2y ago

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.

kbolino 2y ago
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.
pebal 2y ago
Please don't write pauseless if there are short pauses. Pauseless in the Java GC context is a marketing scam.
- pron 2y ago
  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.
  - pebal 2y ago
    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.
    - pron 2y ago
      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).
  - ignoramous 2y ago
    > I was responding to a comment that called the same thing "pausless" In my defense, I called it "~pauseless" (as in, roughly pauseless).
    - vips7L 2y ago
      Pebal is really pedantic about the term in every thread. Because apparently only he has ever achieved pause free GC for his C++ gc.
- gunnarmorling 2y ago
  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.
  - pebal 2y ago
    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.
    - adambatkin 2y ago
      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).
ignoramous 2y ago
> 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).
- pron 2y ago
  > 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 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.

by pron 2y ago

kbolino 2y ago

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.

pebal 2y ago

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

pron 2y ago
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.
- pebal 2y ago
  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.
  - pron 2y ago
    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).
- ignoramous 2y ago
  > I was responding to a comment that called the same thing "pausless" In my defense, I called it "~pauseless" (as in, roughly pauseless).
  - vips7L 2y ago
    Pebal is really pedantic about the term in every thread. Because apparently only he has ever achieved pause free GC for his C++ gc.
gunnarmorling 2y ago
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.
- pebal 2y ago
  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.
  - adambatkin 2y ago
    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).

ignoramous 2y ago

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

pron 2y ago
> 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 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.