7 ms·

As an engineer who lives and breathes java, both in the context of high performance servers and android apps, can someone explain what this does for me besides

As an engineer who lives and breathes java, both in the context of high performance servers and android apps, can someone explain what this does for me besides for quick startup times through the native image feature? what are the benefits of this?

hedora 6y ago
Java’s linker is based on an open world assumption, where you can add arbitrary stuff to the classpath and dynamically link it at runtime. This defeats most compiler optimizations, so you’re left with the JIT. GraalVM makes a closed world assumption, so it can do things like dead code elimination (for library functions that don’t get called), and apply static analysis to inline virtual method calls, perform constant propagation, and so on. This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Basically, it’s like switching from the JIT to a C compiler’s -O3.
- bdibs 6y ago
  And is that with their javac or is it reserved only for their native image generation?
  - smabie 6y ago
    In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.
    - asymptotically2 6y ago
      You need to pay Oracle $lots for a GraalVM enterprise licence to get profile guided optimisations, if you want some of your peak performance back.
    - pjmlp 6y ago
      Twitter thinks otherwise, as they are the major consumer of GraalVM in production.
      - didibus 6y ago
        GraalVM is a JIT compiler for the most part. That's the one Twitter uses I believe. SubstrateVM is what lets you perform a closed world assumption ahead of time build. And that does indeed run left performant most of the time, but it uses less memory and starts faster.
        pjmlp 6y ago
        Unless one feeds it with PGO data, just like it happens in most AOT workflows for optimizations like devirtualization.
      - secondcoming 6y ago
        What part of production, do you know? Because mobile.twitter.com links are slow as hell to load
        pjmlp 6y ago
        Twitter has a couple of talks about it. https://jaxenter.com/graalvm-chris-thalinger-interview-163074.html https://jaxenter.com/graalvm-chris-thalinger-interview-16307...
- marta_morena_25 6y ago
  > This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compilation has otherwise only advantages over static compilcation, especially in highly polymorphic code, such as java. Static compilation for polymorphic code is a joke in terms of performance... And every C++ programmer should know that. I didn't look at the spec, but I would assume that AOT is only the bootup and then the JIT will take over anyway. This means, they'd do some basic precompilation for fat bootup and then use JIT again to optimize the code further based on runtime analysis. Everything else would be a ridicolous step backwards in time and make AOT completely useless, except for some niche scenarios.
  - TimTheTinker 6y ago
    As far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory. (For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that without any special hints in the standard library. Please correct me if I’m wrong... it’s been a few years since I’ve read in depth about TruffleRuby. And granted this example isn’t Java, but I imagine there are great parallels there.)
    - deleted 6y ago
      [deleted]
    - tosh 6y ago
      I'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing? this seems to be a related thread on twitter: https://twitter.com/ChrisGSeaton/status/1001582169578524672 https://twitter.com/ChrisGSeaton/status/1001582169578524672
darksaints 6y ago
Even in JIT mode there is performance improvement due to reduced heap allocation.
de6u99er 6y ago
You can compile your Java code into an executable which doesn't require Java to be present. Advantages would be reduced memory footprint and quicker startup times, which could be ideal for microservices started on demand instead of constantly running. That being said, the people at Spring don't recommend it for production use yet. Here's what they have to say about it: "While GraalVM is now GA, GraalVM native image feature which allows ahead-of-time compilation of Java applications into executable images is only available as an early adopter plugin, so we don't consider it production ready yet." https://github.com/spring-projects/spring-framework/wiki/GraalVM-native-image-support https://github.com/spring-projects/spring-framework/wiki/Gra...
- bmc7505 6y ago
  > You can compile your Java code into an executable which doesn't require Java to be present. Wasn't this feature already supported in JDK 14 with the jpackage tool? https://openjdk.java.net/jeps/343 https://openjdk.java.net/jeps/343
  - nsonha 6y ago
    I believe because dead code elimination isn't currently possible with JVM, "package to binary" would mean including the whole (or most of) JVM with your program.
  - vbsteven 6y ago
    If I understand correctly, the difference between jpackage and GraalVM is this: Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. Graal compiles your full app ahead of time into a native code binary. There is no bytecode/translation happening at runtime. That is why GraalVM advertises faster startup and lower memory footprint. So there are essentially 3 ways to run JVM (Java/Scala/Kotlin/...) code: * compile into bytecode jar -> requires existing VM runtime * compile into bytecode jar + bundle VM runtime -> no dependencies required, runs as the previous option * compile into native binary -> no dependencies required, runs native, starts and runs faster
jariel 6y ago
It's amazing how badly certain companies consistently put their foot in their mouths and cannot even give a basic explanation of what their products to. To compound the inanity - Graal is also the name of a new compiler used in the newer JVMs, in addition to the name of a completely different kind of 'JRE/SDK'. GraalVM allows for polygot execution of a number of languages: Java, Javascript, Python, and anything compiled to LLVM bitcode. It runs them all 'side by side' so there's no translation barrier when interacting between languages. GraalVM also comes with a native compiler that allows you to have much faster startup time, though it comes at the cost of not getting more advanced runtime optimisations. As far as 'performance' I don't think there is anything fundamentally different form the newer JVMs.
pjmlp 6y ago
It is a meta-circular VM, where all layers except for a small glue layer is implemented in Java, already that is quite cool. It grew out of the MaximeVM project at Sun labs. Other well known meta-circular JVM,were Squawk for Sun SPOT and Jikes RVM. Then on top of that, it provides a LLVM like infrastructure to build compilers and language runtimes, all in memory safe language like Java. Additionally there is a long term roadmap to increasingly replace C++ parts of OpenJDK with GraalVM code.
- marvy 6y ago
  > It grew out of the MaximeVM project at Sun labs. I think you mean MaxineVM :)

hedora 6y ago

Java’s linker is based on an open world assumption, where you can add arbitrary stuff to the classpath and dynamically link it at runtime. This defeats most compiler optimizations, so you’re left with the JIT. GraalVM makes a closed world assumption, so it can do things like dead code elimination (for library functions that don’t get called), and apply static analysis to inline virtual method calls, perform constant propagation, and so on. This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Basically, it’s like switching from the JIT to a C compiler’s -O3.

bdibs 6y ago
And is that with their javac or is it reserved only for their native image generation?
- smabie 6y ago
  In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.
  - asymptotically2 6y ago
    You need to pay Oracle $lots for a GraalVM enterprise licence to get profile guided optimisations, if you want some of your peak performance back.
  - pjmlp 6y ago
    Twitter thinks otherwise, as they are the major consumer of GraalVM in production.
    - didibus 6y ago
      GraalVM is a JIT compiler for the most part. That's the one Twitter uses I believe. SubstrateVM is what lets you perform a closed world assumption ahead of time build. And that does indeed run left performant most of the time, but it uses less memory and starts faster.
      - pjmlp 6y ago
        Unless one feeds it with PGO data, just like it happens in most AOT workflows for optimizations like devirtualization.
    - secondcoming 6y ago
      What part of production, do you know? Because mobile.twitter.com links are slow as hell to load
      - pjmlp 6y ago
        Twitter has a couple of talks about it. https://jaxenter.com/graalvm-chris-thalinger-interview-163074.html https://jaxenter.com/graalvm-chris-thalinger-interview-16307...
marta_morena_25 6y ago
> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compilation has otherwise only advantages over static compilcation, especially in highly polymorphic code, such as java. Static compilation for polymorphic code is a joke in terms of performance... And every C++ programmer should know that. I didn't look at the spec, but I would assume that AOT is only the bootup and then the JIT will take over anyway. This means, they'd do some basic precompilation for fat bootup and then use JIT again to optimize the code further based on runtime analysis. Everything else would be a ridicolous step backwards in time and make AOT completely useless, except for some niche scenarios.
- TimTheTinker 6y ago
  As far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory. (For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that without any special hints in the standard library. Please correct me if I’m wrong... it’s been a few years since I’ve read in depth about TruffleRuby. And granted this example isn’t Java, but I imagine there are great parallels there.)
  - deleted 6y ago
    [deleted]
  - tosh 6y ago
    I'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing? this seems to be a related thread on twitter: https://twitter.com/ChrisGSeaton/status/1001582169578524672 https://twitter.com/ChrisGSeaton/status/1001582169578524672

darksaints 6y ago

Even in JIT mode there is performance improvement due to reduced heap allocation.

de6u99er 6y ago

You can compile your Java code into an executable which doesn't require Java to be present. Advantages would be reduced memory footprint and quicker startup times, which could be ideal for microservices started on demand instead of constantly running. That being said, the people at Spring don't recommend it for production use yet. Here's what they have to say about it: "While GraalVM is now GA, GraalVM native image feature which allows ahead-of-time compilation of Java applications into executable images is only available as an early adopter plugin, so we don't consider it production ready yet." https://github.com/spring-projects/spring-framework/wiki/GraalVM-native-image-support https://github.com/spring-projects/spring-framework/wiki/Gra...

bmc7505 6y ago
> You can compile your Java code into an executable which doesn't require Java to be present. Wasn't this feature already supported in JDK 14 with the jpackage tool? https://openjdk.java.net/jeps/343 https://openjdk.java.net/jeps/343
- nsonha 6y ago
  I believe because dead code elimination isn't currently possible with JVM, "package to binary" would mean including the whole (or most of) JVM with your program.
- vbsteven 6y ago
  If I understand correctly, the difference between jpackage and GraalVM is this: Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. Graal compiles your full app ahead of time into a native code binary. There is no bytecode/translation happening at runtime. That is why GraalVM advertises faster startup and lower memory footprint. So there are essentially 3 ways to run JVM (Java/Scala/Kotlin/...) code: * compile into bytecode jar -> requires existing VM runtime * compile into bytecode jar + bundle VM runtime -> no dependencies required, runs as the previous option * compile into native binary -> no dependencies required, runs native, starts and runs faster

jariel 6y ago

It's amazing how badly certain companies consistently put their foot in their mouths and cannot even give a basic explanation of what their products to. To compound the inanity - Graal is also the name of a new compiler used in the newer JVMs, in addition to the name of a completely different kind of 'JRE/SDK'. GraalVM allows for polygot execution of a number of languages: Java, Javascript, Python, and anything compiled to LLVM bitcode. It runs them all 'side by side' so there's no translation barrier when interacting between languages. GraalVM also comes with a native compiler that allows you to have much faster startup time, though it comes at the cost of not getting more advanced runtime optimisations. As far as 'performance' I don't think there is anything fundamentally different form the newer JVMs.

pjmlp 6y ago

It is a meta-circular VM, where all layers except for a small glue layer is implemented in Java, already that is quite cool. It grew out of the MaximeVM project at Sun labs. Other well known meta-circular JVM,were Squawk for Sun SPOT and Jikes RVM. Then on top of that, it provides a LLVM like infrastructure to build compilers and language runtimes, all in memory safe language like Java. Additionally there is a long term roadmap to increasingly replace C++ parts of OpenJDK with GraalVM code.

marvy 6y ago
> It grew out of the MaximeVM project at Sun labs. I think you mean MaxineVM :)