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

21–30 of 108 posts

Re: GraalVM

#21

Post by marta_morena_25 »

hedora wrote: post #6
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?

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…

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

Re: GraalVM

#22

Post by pjmlp »

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

Re: GraalVM

#23

Post by pjmlp »

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.

Twitter thinks otherwise, as they are the major consumer of GraalVM in production.

Re: GraalVM

#24

Post by pjmlp »

eyelidlessness wrote: post #3

So... the polyglot featureset is simultaneously terrifying and super impressive.

While impressive, that was one of the premises for the CLR, and both build on top of language environments from mainframes.

Re: GraalVM

#25

Post by didibus »

pjmlp wrote: post #23
smabie wrote: post #14

Earlier quoted context omitted.

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

Twitter thinks otherwise, as they are the major consumer of GraalVM in production.

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.

Re: GraalVM

#26

Post by TimTheTinker »

marta_morena_25 wrote: post #21
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…

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

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

Re: GraalVM

#27

Post by galaxyLogic »

marta_morena_25 wrote: post #21
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…

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

> Startup time? Granted. Anything else? Not so much.

Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time.

Startup time matters a lot also for micro-services.

A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.

Re: GraalVM

#30

Post by brabel »

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

It's actually jlink that is already available and creates a minimal JVM with your application code that you can distribute as OS-specific bundles... jpackage, which is still in beta (and doesn't work very well, I've tried it recently), will take the output of jlink and turn that into some common OS-specific packages, like RPM, Debian and dmg.
Post reply on HN