9 ms·

I don't really get the need for GraalVM and especially native image part of it. JVMs now a days (incl. OpenJ9) start up fast enough on modern hardware anyways.

I don't really get the need for GraalVM and especially native image part of it. JVMs now a days (incl. OpenJ9) start up fast enough on modern hardware anyways. Going through the complexity of native image generation seems like a solution in search of a problem. I am sure you lose functionality with native image as well - reflection etc. [Edit: I get the point about GraalVM itself just not the native image in the context of kubernetes. With GraalVM maybe they want to optimize better, allow various other languages to run on the JVM etc. None of that is Kuberenetes specific - not much of a memory or startup speed benefit unless I am missing something.]

Thaxll 6y ago
Well probably because no one wants to run Kubernetes sidecar with 256MB of memory because the JVM is memory hungry.
- twic 6y ago
  Graal doesn't reduce you application's memory requirement. If it needs 256 MB if JIT compiled, it will need 256 MB if AOT compiled.
  - thu2111 6y ago
    Actually it does. Native images use about half as much memory or less. Dynamic linking, reflection and speculative JIT compilation are expensive features, memory wise. But you get it back in runtime performance, where native images are slower.
  - gunnarmorling 6y ago
    Not quite; AOT-compiled, your app won't need the JIT infrastructure, less memory needed for class metadata, etc. In addition, Quarkus pulls many things to build time, which classic frameworks do at runtime, e.g. processing XML metadata descriptors. This means again less classes need to be loaded (or even present) at runtime, as e.g. the XML parser classes won't be part of the native image at all. Also see the numbers on quarkus.io, e.g. 28 MB vs. 145 MB RSS for a REST + CRUD app as native binary vs. HotSpot. Disclaimer: working at Red Hat, contributing to Quarkus a bit.
    - twic 6y ago
      I can believe that Quarkus uses a lot less memory than Spring! But not simply using Graal. JIT infrastructure, class metadata, etc are real, of course, but they are a small fraction of total memory use in every app i have ever worked on. Okay, you get a small saving by using Graal, so my original comment is not quite right. But it's not going to make the difference between an app needing 256 MB and 238 MB.
      - jacques_chester 6y ago
        There are two aspects, as I understand it: Graal's native image and Quarkus's compile-time evaluation of annotations. Each is responsible for different aspects of space and time saving. The comparable compile-time effort in Spring is being explored in the spring-init project[0] and I believe will be a core feature in Spring Boot 3 / Spring Framework 6, along with Graal support. [0] https://github.com/spring-projects-experimental/spring-init https://github.com/spring-projects-experimental/spring-init
oweiler 6y ago
Not fast enough for serverless or commandline apps. Native images also consume much less memory (up to a 1/4 or even 1/5) which can save you a lot of money when using cloud services.
dimitar 6y ago
Startup time doesn't matter for long-running applications. It makes sense for things like lambda or knative ("serverless"). Also command-line applications (including tools you might put in CI). Also, while the JVM starts quickly you also need to do class loading, which can take a while for complex applications with lots of classes. This is also pretty important when running a JVM-hosted language like Clojure which has quite a few classes of its own.
- deleted 6y ago
  [deleted]
eternalban 6y ago
Native Image is a utility. You don't have to use it. https://www.graalvm.org/why-graalvm/ https://www.graalvm.org/why-graalvm/
barrkel 6y ago
If you're starting jobs in response to queues, you want those jobs to start quickly. And if you're starting a lot of jobs, the less memory they consume, the more of them you can pack in your cluster and the less you need to autoscale your cluster. Quarkus uses build-time steps for most of what would be done at runtime (DI, mapping, routing etc.) in Spring. This makes it faster to start up and reduces reflection overhead even when not using GraalVM.
- eropple 6y ago
  Micronaut does this too. Why use Quarkus over it?
  - barrkel 6y ago
    It's true, they're similar. Quarkus leans a bit more towards Java EE, Micronaut a bit more towards Spring. I don't think it would be worth switching from one to the other.
    - eropple 6y ago
      Cool, thank you! I've never seen Quarkus before so it's new to me, but I've had some success with Micronaut so I was a little confused. Surprised they don't work together; the goals do seem very similar.
pm90 6y ago
Many simple apps don’t really need all the optimizations that the JVM offers. The vast majority of applications are probably going to have loads that can be handled just fine by running as native image. On the other hand, memory and CPU cost real dollars, and saving that can have a pretty huge impact on costs. So the build time complexity may just be ok if I get to save a bunch of money by scaling down the amount of nodes I need for my K8s apps.
exabrial 6y ago
You're missing the point of GrallVm: Write the compiler in Java, not CPP. That greatly relaxes the curve and cross sectional skillet required to implement this function: byte [] compileToNative(byte[] byteCode);
blntechie 6y ago
One word answer - Lambda.
bogomipz 6y ago
In the context of Kubernetes I can see how startup time matters. For instance auto-scaling up the number of replicas in response to load. The other one I can think of is serverless frameworks such as Knative where you might be using a scale-from-zero model where you are spinning up a service on demand.
pjmlp 6y ago
Free beer AOT, AOT compilers exist in commercial JDKs since the early 2000's. A compiler/JIT development stack not bound to the cargo cult that C and C++ are the only path to system software.
AzzieElbab 6y ago
I just build a container of scala graphql server compiled with graal. It is 70mb in size, probably smaller than some js bundles on modern websites. It is static, meaning I can’t mess up class path or jvm versions while deploying
gunnarmorling 6y ago
If you have users waiting for cold starts (e.g. AWS Lambda without "provisioned concurrency"), the JVM start-up still is problematic, despite all the great improvements that recently have been made (OpenJDK 15 again got some nice improvements, e.g. related to AppCDS). I'm discussing this in this post about a Serverless blog search I've built with Quarkus and Lambda: morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/. Disclaimer: working at Red Hat, contributing to Quarkus a bit.

Thaxll 6y ago

Well probably because no one wants to run Kubernetes sidecar with 256MB of memory because the JVM is memory hungry.

twic 6y ago
Graal doesn't reduce you application's memory requirement. If it needs 256 MB if JIT compiled, it will need 256 MB if AOT compiled.
- thu2111 6y ago
  Actually it does. Native images use about half as much memory or less. Dynamic linking, reflection and speculative JIT compilation are expensive features, memory wise. But you get it back in runtime performance, where native images are slower.
- gunnarmorling 6y ago
  Not quite; AOT-compiled, your app won't need the JIT infrastructure, less memory needed for class metadata, etc. In addition, Quarkus pulls many things to build time, which classic frameworks do at runtime, e.g. processing XML metadata descriptors. This means again less classes need to be loaded (or even present) at runtime, as e.g. the XML parser classes won't be part of the native image at all. Also see the numbers on quarkus.io, e.g. 28 MB vs. 145 MB RSS for a REST + CRUD app as native binary vs. HotSpot. Disclaimer: working at Red Hat, contributing to Quarkus a bit.
  - twic 6y ago
    I can believe that Quarkus uses a lot less memory than Spring! But not simply using Graal. JIT infrastructure, class metadata, etc are real, of course, but they are a small fraction of total memory use in every app i have ever worked on. Okay, you get a small saving by using Graal, so my original comment is not quite right. But it's not going to make the difference between an app needing 256 MB and 238 MB.
    - jacques_chester 6y ago
      There are two aspects, as I understand it: Graal's native image and Quarkus's compile-time evaluation of annotations. Each is responsible for different aspects of space and time saving. The comparable compile-time effort in Spring is being explored in the spring-init project[0] and I believe will be a core feature in Spring Boot 3 / Spring Framework 6, along with Graal support. [0] https://github.com/spring-projects-experimental/spring-init https://github.com/spring-projects-experimental/spring-init

oweiler 6y ago

Not fast enough for serverless or commandline apps. Native images also consume much less memory (up to a 1/4 or even 1/5) which can save you a lot of money when using cloud services.

dimitar 6y ago

Startup time doesn't matter for long-running applications. It makes sense for things like lambda or knative ("serverless"). Also command-line applications (including tools you might put in CI). Also, while the JVM starts quickly you also need to do class loading, which can take a while for complex applications with lots of classes. This is also pretty important when running a JVM-hosted language like Clojure which has quite a few classes of its own.

deleted 6y ago
[deleted]

eternalban 6y ago

Native Image is a utility. You don't have to use it. https://www.graalvm.org/why-graalvm/ https://www.graalvm.org/why-graalvm/

barrkel 6y ago

If you're starting jobs in response to queues, you want those jobs to start quickly. And if you're starting a lot of jobs, the less memory they consume, the more of them you can pack in your cluster and the less you need to autoscale your cluster. Quarkus uses build-time steps for most of what would be done at runtime (DI, mapping, routing etc.) in Spring. This makes it faster to start up and reduces reflection overhead even when not using GraalVM.

eropple 6y ago
Micronaut does this too. Why use Quarkus over it?
- barrkel 6y ago
  It's true, they're similar. Quarkus leans a bit more towards Java EE, Micronaut a bit more towards Spring. I don't think it would be worth switching from one to the other.
  - eropple 6y ago
    Cool, thank you! I've never seen Quarkus before so it's new to me, but I've had some success with Micronaut so I was a little confused. Surprised they don't work together; the goals do seem very similar.

pm90 6y ago

Many simple apps don’t really need all the optimizations that the JVM offers. The vast majority of applications are probably going to have loads that can be handled just fine by running as native image. On the other hand, memory and CPU cost real dollars, and saving that can have a pretty huge impact on costs. So the build time complexity may just be ok if I get to save a bunch of money by scaling down the amount of nodes I need for my K8s apps.

exabrial 6y ago

You're missing the point of GrallVm: Write the compiler in Java, not CPP. That greatly relaxes the curve and cross sectional skillet required to implement this function: byte [] compileToNative(byte[] byteCode);

blntechie 6y ago

One word answer - Lambda.

bogomipz 6y ago

In the context of Kubernetes I can see how startup time matters. For instance auto-scaling up the number of replicas in response to load. The other one I can think of is serverless frameworks such as Knative where you might be using a scale-from-zero model where you are spinning up a service on demand.

pjmlp 6y ago

Free beer AOT, AOT compilers exist in commercial JDKs since the early 2000's. A compiler/JIT development stack not bound to the cargo cult that C and C++ are the only path to system software.

AzzieElbab 6y ago

I just build a container of scala graphql server compiled with graal. It is 70mb in size, probably smaller than some js bundles on modern websites. It is static, meaning I can’t mess up class path or jvm versions while deploying

gunnarmorling 6y ago

If you have users waiting for cold starts (e.g. AWS Lambda without "provisioned concurrency"), the JVM start-up still is problematic, despite all the great improvements that recently have been made (OpenJDK 15 again got some nice improvements, e.g. related to AppCDS). I'm discussing this in this post about a Serverless blog search I've built with Quarkus and Lambda: morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/. Disclaimer: working at Red Hat, contributing to Quarkus a bit.