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.

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.

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.

Unless one feeds it with PGO data, just like it happens in most AOT workflows for optimizations like devirtualization.

What part of production, do you know? Because mobile.twitter.com links are slow as hell to load

Twitter has a couple of talks about it.

https://jaxenter.com/graalvm-chris-thalinger-interview-16307...

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

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

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

Are you unsure about the runtime considerations or how the compiler would infer the necessary optimizations?

Can the storage of generic containers change as well? For example, store the objects in the container instead of reference?

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

> Java never got to the desktop (including browser)

What do you mean by this? There are a lot of desktop Java applications...

I'd like to hear about them, because apart from enterprise applications, there aren't that many left. Electron is the new desktop Java.

I wouldn't call them dominant by any stretch, but I wouldn't call them uncommon. Ones I use somewhere between daily and semi-regularly:

* Pycharm * Datagrip * Charles * JDiskReport * TexturePacker * Android Studio and associated tools * Apache Directory Studio * Zed attack proxy

That's just stuff that I've used recently and on an ongoing basis... I feel like I see quite a bit more of it.

I used to use a thing called JMeter. But its GUI felt inferior in my view compared to typical Windows applications.

> The reason Java never got to the desktop (including browser) I believe was the startup time.

I think it's mainly the fact that it has always been very difficult to create executable files.

Running java requires you to install the given version of JRE instead of just downloading an application and starting it.

It was always very easy, just package the JRE with the application, use an installer like any other desktop application, or buy one of those commercial AOT compilers available since the start of century.

But that takes a lot of space

You could not fit it on a floppy

The 8 and 16 bit home computer scene are way past us.

There's also an expectation that memory footprint will be lower and that can contribute to speed by reducing GC time. The "JIT can do it too" arguments generally don't consider bounded memory.

Hehehe the old AOT vs JIT debate.

JITs can do great optimizations in theory. But in practice they have only so much time to do optimizations.

And startup time, binary distribution size, memory footprint matter too.

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.

> It grew out of the MaximeVM project at Sun labs.

I think you mean MaxineVM :)

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

As a counter-point, Quarkus [1] has mature support for building Java apps as native binaries via GraalVM, with a large number of extensions that enable 3rd party libraries to be used in native binaries, and people use this successfully in production. Issues from the past, like lack of debug symbol support with GraalVM CE, have also been resolved by now.

Shameless plug for one real-world usage: the search feature of my personal blog is built as a GraalVM native binary, running as a serverless app on AWS Lambda [3].

Disclaimer: I work for Red Hat, who sponsor the development of Quarkus

[1] https://quarkus.io/

[2] https://quarkus.io/guides/

[3] https://www.morling.dev/blog/how-i-built-a-serverless-search...

While what Quarkus promises sounds delightful, the actual dev experience is still not something I'd recommend. The amount of libraries one can use is still very limited. The compiler errors when one chooses to step outside of the approved list of supported libraries, are very cryptic (or non-existent). In my case, I tried to use Apache Freemarker for templating. I could've tried Quarkus' own templating library, but it didn't exist at that time. What was worse, I had to shut down nearly every app on my 16 Gigabyte, 6-core machine to compile the image! If I didn't do that, compilation would fail with no useful info. The Quarkus team does a wonderful job of demoing a Hello World example. I was just unable to achieve the same success. I love what they're trying to build, so I'll check back with regularity. Our one Quarkus app is using OpenJDK 1.8 for the time being.

Agreed that the experience when trying to native-enable existing libs isn't the greatest. Altough those things are rather reported by the GraalVM compiler rather than Quarkus. The working model and assumption is that somebody goes through this once and then either contributes changes to the library in question back upstream or provides a Quarkus extension for that library, sparing others from that hassle.

That RAM consumption sounds definitely over the top; if you still have the context, logging an issue would be very welcomed. That said, there's many libraries enabled by Quarkus (see quarkus.io/guides/), so every essential functionality should be covered by now. Still a question of course whether your specific library in a given space (like FreeMarker vs. Quarkus Qute) already is supported. In any case, thanks for checking back in regularly, things might look better next time already, as the framework evolves rapidly.

Isn't native-image memory consumption and compile time basically a known issue by the graal team?

Note that Quarkus starts very fast on Java 14 too. With JDK 14 their hello world app starts in about 600msec on my laptop. HotSpot got optimised a lot over the years and Quarkus gets some of its speed boost by just doing less dynamic stuff at startup.

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.

You're not wrong, but with Java evolving rapidly, we're in a situation where there are dozens of commonly used JVM versions in the wild... being able to ship the most recent JVM (which can be as little as 25MB depending on which JDK modules you depend on) with your application not only allows you to benefit from using modern language features, but it also makes your application safer by using the latest runtime with the most up-to-date security fixes, not to mention performance and testing becomes a lot easier when you only have one JVM version to worry about. Also, you can have both options. I have a somewhat popular Java app that I distribute as a tiny jar (300KB, requires Java 9+) and as a stand-alone app (packaged with jlink, around 35MB including JDK 11) - and users can choose which one they want.

> 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

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

This is incorrect. Jpackage creates an installer which will unpack the VM image and any other resources.

I've tried it with a small CLI tool and it actually doesn't work that well (at least on Windows).

Makes sense, thanks for clarifying!

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.

> and doesn't work very well, I've tried it recently)

This is my experience as well. After installation, my installed app just didn't do anything.

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.

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.

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