4 ms·

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

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

pjmlp 2y ago
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.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ https://eclipse.dev/openj9/docs/aot/ https://eclipse.dev/openj9/docs/aot/ https://www.ibm.com/docs/en/sdk-java-technology/8?topic=reference-aot-compiler https://www.ibm.com/docs/en/sdk-java-technology/8?topic=refe... Now gone, https://en.wikipedia.org/wiki/Excelsior_JET 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.
- ignoramous 2y ago
  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.html 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.
  - pjmlp 2y ago
    > 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.
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.
      - 2y ago
ksec 2y ago
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.

pjmlp 2y ago

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.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ https://eclipse.dev/openj9/docs/aot/ https://eclipse.dev/openj9/docs/aot/ https://www.ibm.com/docs/en/sdk-java-technology/8?topic=reference-aot-compiler https://www.ibm.com/docs/en/sdk-java-technology/8?topic=refe... Now gone, https://en.wikipedia.org/wiki/Excelsior_JET 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.

ignoramous 2y ago
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.html 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.
- pjmlp 2y ago
  > 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.

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

ksec 2y ago

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.