Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM

graalvm.org

Post reply on HN
Print view View original

11–20 of 108 posts

Re: GraalVM

#11

Post by bmc7505 »

de6u99er wrote: post #9
greatjack613 wrote: post #5

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?

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 f…

> 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

Re: GraalVM

#12

Post by jariel »

greatjack613 wrote: post #5

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?

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.

Re: GraalVM

#13

Post by sanxiyn »

ridiculous_fish wrote: post #10

Can someone please give a sober explanation of what GraalVM, is and how Truffle works? I think it is somewhat analogous to LLVM: Graal exposes a "language agnostic" API which allows multiple front-ends. There's a front-end for Ruby, JS, C++, others. But this API is higher level than LLVM: it knows about objects, and allows tricks like querying properties across language boundaries. But I can't imagine what this API l…

Here is Truffle's Javadoc: https://www.graalvm.org/truffle/javadoc/overview-summary.htm...

See especially Assumption, CallTarget, and DynamicObject.

Re: GraalVM

#14

Post by smabie »

bdibs wrote: post #8
hedora wrote: post #6

Earlier quoted context omitted.

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…

And is that with their javac or is it reserved only for their native image generation?

In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.

Re: GraalVM

#15

Post by nsonha »

bmc7505 wrote: post #11
de6u99er wrote: post #9

Earlier quoted context omitted.

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 f…

> 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

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.

Re: GraalVM

#16

Post by asymptotically2 »

smabie wrote: post #14
bdibs wrote: post #8

Earlier quoted context omitted.

And is that with their javac or is it reserved only for their native image generation?

In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.

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.

Re: GraalVM

#17

Post by vbsteven »

bmc7505 wrote: post #11
de6u99er wrote: post #9

Earlier quoted context omitted.

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 f…

> 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

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

Re: GraalVM

#18

Post by bmc7505 »

vbsteven wrote: post #17
bmc7505 wrote: post #11

Earlier quoted context omitted.

> 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

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…

Makes sense, thanks for clarifying!

Re: GraalVM

#19

Post by erik_seaberg »

de6u99er wrote: post #9
greatjack613 wrote: post #5

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?

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 f…

Static linking is back in fashion, but it means many stale copies of the guts of Java are present, where before we had just one complete and managed copy. It's very similar to bundling your own libc when pretty much every system already has one.

Re: GraalVM

#20

Post by kasperni »

GraalVM consists of a couple of things.

1. A modern JIT compiler written in Java that takes bytecode and transforms it into machine code. There is a plan that it might someday replace HotSpot [1]. However, we are probably a couple of years away from this.

2. A native image compiler [2] that uses ahead-of-time compilation technology to produce executable binaries of class files. This means startup times and memory usage similar to a language such as go.

3. An abstract syntax tree interpreter called Truffle. Which allows you to easily implement languages on top of GraalVM. With the performance of compiled languages but using an interpreter. You can read more about this here [3].

There are also other features such as a LLVM bitcode engine called Sulong. And various PolyGlot functionality to support integration of whatever language you want. [4]

[1] https://jaxenter.com/openjdk-project-metropolis-137318.html

[2] https://www.graalvm.org/docs/reference-manual/native-image/

[3] https://www.beyondjava.net/truffle-compiler-compiler

[4] https://github.com/oracle/graal/blob/master/sulong/README.md

Post reply on HN