11 ms·

In fact, Oracle also funds the open-source version, OpenJDK. The Oracle EE JDK has some extra features which can be enabled (e.g. fancier G1 garbage collector,

In fact, Oracle also funds the open-source version, OpenJDK. The Oracle EE JDK has some extra features which can be enabled (e.g. fancier G1 garbage collector, IIRC), and there's also GraalVM EE which provides an even faster runtime. Also worth noting GraalVM CE (Community Edition) which is pretty spectacular. Futamura Projection, anyone? https://en.wikipedia.org/wiki/Partial_evaluation https://en.wikipedia.org/wiki/Partial_evaluation (This is the badass future space tech part of Graal :) That said, OpenJDK works totally fine for many cases.

pharaohgeek 2y ago
Compiling Java to native code via GraalVM is really amazing. The Quarkus framework supports this, and the startup time and memory utilization is incredible compared to the JVM. I deploy native-built Java apps as AWS Lambdas and the startup time and resource utilization are so much better by comparison.
- willsmith72 2y ago
  what are the cold starts like?
  - metadat 2y ago
    Faster, because it's a native executable.
    - willsmith72 2y ago
      Right, but I mean there's faster than spring boot (30 seconds), then there's fast enough for a typical web experience (<500ms) My experience on lambda is with node and python, and I've always needed to pay for concurrency. Cold starts were 1-3s, which is not good enough for a web api
      - mike_hearn 2y ago
        A GraalVM native executable can start faster than a C program. Think tens of milliseconds.
        degaart 2y ago
        Source and benchmarks please
        mike_hearn 2y ago
        There are lots. Everyone gets those sorts of results so you can just try it, or here are some experience reports: https://debijenkorf.tech/speed-up-application-launch-time-with-graalvm-3d629131adb1 https://debijenkorf.tech/speed-up-application-launch-time-wi... > The app went from starting in 463ms to a whopping 7ms, awesome! > As you can see the memory usage went from 215.924kB to 18.104kB Or for Lambdas (this result is reported by the GraalVM team): > The same Lambda function with 3008 MB of memory that took 3.6 seconds to start with the JVM, started in under 100 milliseconds once compiled using GraalVM https://aws.amazon.com/blogs/opensource/improving-developer-productivity-at-disney-with-serverless-and-open-source/ https://aws.amazon.com/blogs/opensource/improving-developer-... Native Image is a fully independent JVM and compiler implementation that was written from day one for startup time and memory footprint as the only goals that mattered. What it sacrifices to get that is some semantic compatibility. The big differences are: - It compiles all code ahead of time. As machine code is much bigger than the equivalent bytecode, it uses a dead code ("tree shaking") analysis to only compile code that's statically reachable or declared via config files. It's like a mandatory WebPack or ProGuard step if you're familiar with those. - It runs (some) class initializers at compile time, not startup time. So if you do something like "public static final Thread thread = ...." then you'll need to exclude that class from build-time init, including if it's in libraries etc. - It snapshots the post-compile heap into the binary. So this is changing the normal Java semantics and that means some apps won't run on native image without some up front work. It's not an entirely free capability. You have to "port" your app to it. Fortunately, because the startup and memory footprint wins are so huge and definitive the JVM ecosystem is rallying around this approach and making frameworks and such compatible with it. For instance if you use the latest versions of any of the modern Java web frameworks (Spring, Micronaut, Quarks, etc) then you can easily run a single build system target to get a Docker container with a native executable inside, that has those startup times you're seeing here. At this point the startup time bottleneck for (compatible) Java apps has shifted to the kernel; the container infrastructure itself takes longer to start than the Java program does.

pharaohgeek 2y ago

Compiling Java to native code via GraalVM is really amazing. The Quarkus framework supports this, and the startup time and memory utilization is incredible compared to the JVM. I deploy native-built Java apps as AWS Lambdas and the startup time and resource utilization are so much better by comparison.

willsmith72 2y ago
what are the cold starts like?
- metadat 2y ago
  Faster, because it's a native executable.
  - willsmith72 2y ago
    Right, but I mean there's faster than spring boot (30 seconds), then there's fast enough for a typical web experience (<500ms) My experience on lambda is with node and python, and I've always needed to pay for concurrency. Cold starts were 1-3s, which is not good enough for a web api
    - mike_hearn 2y ago
      A GraalVM native executable can start faster than a C program. Think tens of milliseconds.
      - degaart 2y ago
        Source and benchmarks please
        mike_hearn 2y ago
        There are lots. Everyone gets those sorts of results so you can just try it, or here are some experience reports: https://debijenkorf.tech/speed-up-application-launch-time-with-graalvm-3d629131adb1 https://debijenkorf.tech/speed-up-application-launch-time-wi... > The app went from starting in 463ms to a whopping 7ms, awesome! > As you can see the memory usage went from 215.924kB to 18.104kB Or for Lambdas (this result is reported by the GraalVM team): > The same Lambda function with 3008 MB of memory that took 3.6 seconds to start with the JVM, started in under 100 milliseconds once compiled using GraalVM https://aws.amazon.com/blogs/opensource/improving-developer-productivity-at-disney-with-serverless-and-open-source/ https://aws.amazon.com/blogs/opensource/improving-developer-... Native Image is a fully independent JVM and compiler implementation that was written from day one for startup time and memory footprint as the only goals that mattered. What it sacrifices to get that is some semantic compatibility. The big differences are: - It compiles all code ahead of time. As machine code is much bigger than the equivalent bytecode, it uses a dead code ("tree shaking") analysis to only compile code that's statically reachable or declared via config files. It's like a mandatory WebPack or ProGuard step if you're familiar with those. - It runs (some) class initializers at compile time, not startup time. So if you do something like "public static final Thread thread = ...." then you'll need to exclude that class from build-time init, including if it's in libraries etc. - It snapshots the post-compile heap into the binary. So this is changing the normal Java semantics and that means some apps won't run on native image without some up front work. It's not an entirely free capability. You have to "port" your app to it. Fortunately, because the startup and memory footprint wins are so huge and definitive the JVM ecosystem is rallying around this approach and making frameworks and such compatible with it. For instance if you use the latest versions of any of the modern Java web frameworks (Spring, Micronaut, Quarks, etc) then you can easily run a single build system target to get a Docker container with a native executable inside, that has those startup times you're seeing here. At this point the startup time bottleneck for (compatible) Java apps has shifted to the kernel; the container infrastructure itself takes longer to start than the Java program does.