▲ 190 points
back
86 comments
GraalVM is interesting technology. I've been playing a little bit with native-image in a Kotlin project and it allows me to build native binaries from my Kotlin code. With support for a lot of the existing java/kotlin library ecosystem.
The binaries are a bit large (10MB for a Kotlin hello world) but they are fast. I'll be using this for some personal cli tools since Kotlin+Maven is my personal 10x platform.
Besides cli projects I've also done some experimentation with GUI and database stuff. Using the Gluon plugin GraalVM is able to compile a native binary for a JavaFX app that talks to a Sqlite database.
When using a library that relies on reflection there might be some graalvm config to fiddle with but mostly it just works, and some of the libraries are already "native-image ready" with the necessary config inside the published package.
Have you tried taking a look at UPX for the binary size? I found that it significantly decreased the size of the binary to the point where the problem was more the size of my dependencies (large JARs that could not be optimized away) and could get the binary to a completely manageable place. They aren't C small, but they were definitely better than traditional Java apps by an order of magnitude.
I had not heard of UPX until just now and just did a quick test. With `-7` level it brings the 10MB binary down to 3.6MB but execution time was roughly x10.
UPX doesn't play nice with antivirus software if it's important for you to run on Windows (at least).
How smooth is JavaFX compilation to native? Any bugs/issues running the native version of JavaFX UI application?
Thanks
native-image takes a minute to compile the binary from the jar but after that it's pretty smooth. I noticed my css styles where a bit different here and there but that could be due to differences in the default stylesheet used in my jvm build (OpenJDK with OpenJFX) vs the native-image build (using Gluon and maybe a customized JavaFX version)
That's awesome to hear! If you could share any working Hello World repos or similar using Gluon and SQLite I would massively appreciate it. About 5 years ago I developed a GUI desktop app with TornadoFX, Spring Boot and SQLite and it turned out to be incredibly solid, and I've always wanted to go back and try to find out a quick template repo with Gluon to try and do more small desktop apps again.
I'm working on it but nothing to share yet. I think Gluon itself has a few starter/example projects. The Xerial sqlite library already has native-image configuration files in its build so no extra config required. I'm still trying to get Jdbi to work fully with native-image and once that is done I will create a PR there. But my time is limited in the next week or two.
Also, I'm using plain JavaFX with Kotlin instead of TornadoFX. Mostly because I'm not sure about the health of the TornadoFX project and I don't like some of its abstractions.
Do you have a link to any example repos by chance? The need has slowly been growing for some cli tools I want to write, but I haven't taken the plunge yet. I'm the most curious about peeking at your maven setup.
I don't have anything public right now but the setup is pretty simple (although I use Gradle with the Kotlin DSL instead of Maven). It's your standard kotlin or java setup that can build a jar with dependencies included, and 1 extra build step to invoke `native-image` from the Graal SDK.
Is Jetbrains Desktop Compose Graal compatible ?
I tried Graal/Truffle last year, to make a toy language of my own. Unfortunately the state of documentation and tutorials was simply not good enough and I had to give up on it. I think for someone who is a Java/Graal enthusiast, Truffle documentation may be enough, but for someone like me who knows just the basics of Java and its ecosystem, the Truffle language implementation docs seemed woefully inadequate.
Its a shame though, for what I did understand of Truffle seemed very interesting. I do plan on trying truffle yet again in a few years, when hopefully the community size and the state of the documentation have improved.
Do you have any feedback on how we could improve the docs? If so, please let us know.
I believe the easiest way to start a new Truffle language implementation is to fork SimpleLanguage [1] and turn it into your language. Did you try to do that?
Yes please.
My major blockers were -
1. Starting post ast generation was an abrupt start. An end to end tutorial - from parsing to working compiler for a tiny language like Lua, Lox, Wren etc would be very helpful. You need not deep dive into the parsing part - just give enough that we can follow along. Another option can be to continue an existing tutorial series like Lox from "crafting interpreters". That way you don't have to focus on parts which are not Truffle specific, yet users can follow along.
2. Just going through existing Java code of the Simple Language was extremely difficult for a newbie to Java, like me. I would much prefer a readable tutorial which explains all concepts in more details
3. More language examples please. As I said before, if possible do add a couple more languages like Lua. I believe Lua is already a Truffle language. Just an accompanying tutorial is missing. I remember when I tried to read through the codes of Ruby, Lua and simple language, they all started off very differently and I just got lost.
I think the issue here is that the Truffle docs:
a. Point people to the papers to understand how the 'magic' happens.
b. Are really intended for people who already know how to build language VMs from scratch.
If you've never implemented a language interpreter at all, then you're going to struggle. Arguably not Truffle's fault, but hey, you can't drop the cost of making SOTA language runtimes by a couple orders of magnitude and then be surprised when a whole lot of newbies show up wanting to try their hand at it :)
I am sorry to hear you did not succeed in building your own language. I have to admit it is quite a steep learning curve. If you decide to retry do not hesitate to hit us up with questions on the community slack. We are a helpful bunch.
Also I will drop my truffle seminar shamelessly here for you to watch: https://youtu.be/pksRrON5XfU
I was in a similar place. I tried implementing a toy language with it but it felt like I had to be very comfortable in Java-land to be able to use it, I just didn't have the desire to put that much effort :P
But I'm sure it's a great technology and with time the docs will get better and better.
Did you join the Slack group? People there will give you all the time and help you need.
I did and to be fair the people there were very helpful. It's just that I needed more hand holding than the average person (as I was new to Java as well)
> Graal was included in HotSpot-based Java VM releases like OpenJDK from Java 9 through 15, but was removed in Java 16 for lack of use.
From wikipedia [0].
What's the deal with GraalVM today? I guess Oracle is still keeping it alive since this is a post by an Oracle team.
Does it have a future or is it going to be abandoned or what is the plan?
[0] https://en.wikipedia.org/wiki/GraalVM#:~:text=The%20GraalVM%....
As mentioned by sibling poster, it really is not a setback, they just have different release schedules.
Graal is doing pretty well, it is heavily used by Twitter for example. And the polyglot part is simply completely novel and very exciting - it can basically optimize across language boundaries with it. A python call to a C function might get inlined and be much faster than native FFI. Enterprise edition also has managed mode for LLVM bitcode, making for example existing C code use managed heap for allocations. TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin and the JS runtime developed by comparatively few people (compared to V8 and the like) can achieve similar performance to it.
TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin
This is interesting to me as someone working on a Rails app currently. I'm surprised it hasn't become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? Just Oracle ownership? Or does it require an enterprise subscription?
20 years ago, I was a lurker on the JikesRVM (IBM's research project building a JVM in Java) mailing list. JikesRVM is still around, but not terribly active last I checked. Oracle is quite late to the game, and I'm just generally sad that Oracle ended up owning Java instead of IBM (or perhaps Google, but my trust in Google seems to be monotonically decreasing).
Last I checked, Oracle's AoT compiler threw away any metadata necessary for HotSpot to be able to trace its way trough the native code, so if your AoT-compiled code was part of a hot loop, HotSpot wouldn't be able to perform any inlining or other runtime optimizations of your code. It seems like fixing this would be a first step to having a high performance JVM written in Java with start-up/warm-up time comparable to a JVM written in C++.
While we're at it, Erlang/Elixir/BEAM's NIFs seem the right way to implement native code extensions to your VM. You write implementations in your language that get replaced with native versions if the native library is successfully loaded. Maybe your non-native implementation is just a stub that throws if it's called. With a few lines at the top of your module, you can attempt to load one or more native libraries and handle/ignore any errors. This makes it much easier to gracefully degrade if a particular native library isn't available on the local machine (or even available for the platform). It's a real pain to fall back to a Java implementation if the JNI implementation isn't available for any reason.
It was Oracle that turned the MaximeVM research project into GraalVM, bringing it outside of the research lab.
IBM would have killed it instead, J9 already provides AOT and JIT caches, almost a decade older before such capabilities landed on OpenJDK.
GraalVM has always been built and maintained outside of the OpenJDK. Staring with Java 9 Oracle started including it with OpenJDK to provide AOT compilation, but as the article says, it wasn't widely adopted by OpenJDK users.
Most people who wanted AOT would use GraalVM directly, so for most people nothings changed. Those that did use the OpenJDK AOT will have to migrate to using GraalVM's tooling post Java 15.
To my knowledge, another reason for the exclusion of Graal from OpenJDK was the different release cycle of development.
I’m not sure including it in OpenJDK was ever a major goal, so removing it wasn’t the setback I think you’re mistaking it for.
Yeah could be. I was just thinking that organizationally being part of OpenJDK sounds like a big thing and pulling back from that sounds like a reversal of a big thing. I'm sure the team wasn't extremely happy about it.
If you love GraalVM, and very small app sizes, and get a nice dependency injection framework to break your code up into testable modules, be sure to check out https://quarkus.io . Be sure to scroll down to the memory and start time benchmarks :)
Cool! I vaguely remember about Microanus framework being in the similar area, there are also a couple more others (I don't remember the name.)
How do these Graal native-ish frameworks compare? Or more broadly, what does the scene look like today?
Micronaut (from Grails developers) was an early Graal adopter and is very actively developed and has a growing ecosystem around it.
However, Quarkus has many distinguishing features beyond a nice dependency injection framework. First of all it is a Microprofile implementation - Microprofile is a collaborative effort among many large companies to adapt and evolve pieces of enterprise java stack to microservices. So large parts of your application would depend on Microprofile API rather than APIs specific to a particular framework like Quarkus and will be portable across Microprofile implementations (like Helidon or OpenLiberty) - for smaller individual services the benefits are minimal but it is a major advantage for larger corporations putting in decade long investments. Also, Quarkus is built atop vert.x which provides a non blocking event-loop and actor(-like) framework for JVM. Developers can choose to not bother with vert.x at all and use the MP apis exclusively but for people who like the actor-oriented programming model can choose to take advantage of it (perhaps for specific use cases). Lastly, as can be expected because it is by Redhat, there is out of the box integration with Hibernate.
Regarding the scene, Spring is also pushing into the Graal ecosystem with native features - but they are still a bit late to party. They do have a huge ecosystem to support and can't afford breaking changes so it is understandable that good spring support for Graal is an evolving multi-year effort. But it does mean that early adopters like Micronaut and Quarkus have an edge.
Also, irrespective of how well mainstream adoption for Graal pans out, I am quite happy about the growing initiative to move start-time work to build time which improves start times for non-graal deployments too.
My world revolves around Common Lisp (with Python for deep learning), but Clojure is also an important language to me because of both professional use and I wrote a Clojure AI book.
What is the Graalvm + Clojure situation? A quick web search shows some use cases. I find the idea of using high programmer-efficient Lisp languages and then building small and fast native applications to be compelling. That said, LispWorks, SBCL, and Allegro CL are all good for building standalone apps.
Examples of Clojure projects that compile to native:
- babashka (https://github.com/babashka/babashka)
- clj-kondo (https://github.com/clj-kondo/clj-kondo)
- jet (https://github.com/borkdude/jet)
SCI (https://github.com/babashka/sci) is a Clojure interpreter that allows you to evaluate Clojure code even inside of the final native binary and is used in all of the above projects.
Feel free to bug me with questions in the graalvm channel on Clojurians Slack.
I want to slap a bunch of side projects on a small VPS. With Go, this is no problem. Scp the binary (which includes an embedded SQLite), configure it to run as a systemd service, add it to my reverse proxy rules.
I’d love to use Clojure for this, but it doesn’t seem well suited to running in a small, shared environment. Or is it now that there’s AOT?
Thanks for the info!
BTW, I enjoyed your ClojureScript+Node.js talk a few weeks ago.
If you have a clojure project that builds to a single .jar file at hand, you can give it a quick shot using the native-image command from the GraalVM. If you're not using reflection-heavy libraries chances are it will just work and spit out a binary.
It can compile Clojure to native executables but do note that Graal’s AOT part doesn’t promise better performance, just faster startup time and reduced memory usage. Using JIT compilers for long running processes (either the usual OpenJDK’s hotspot or Graal’s JIT compiler) will very likely beat the AOT compiled version for long running processes.
I'm running Clojure code compiled with GraalVM native for AWS Lambda. Cold start times are low and performance is decent enough, even with CE edition. The whole process is reasonably painless through the use of Holy Lambda https://github.com/FieryCod/holy-lambda
Not quite what you were asking for, but I wanted to chip in as another happy Clojure + GraalVM native user.
I haven't touched GraalVM in a couple years, but the big-ish project that I did with it in Clojure was mostly painless, except for the fact that I had to use type-hinting a lot more frequently, due to the reduced reflection capabilities of GraalVM.
Other than that, it was actually very pleasant.
I think Project Loom support will open up green thread support for more Truffle-based languages. I could see Go, Haskell, Erlang, Scheme, and Concurrent ML -style languages taking advantage of that infrastructure.
I'm also hoping for official support for static linking. Right now, it's an undocumented feature done through the Feature API.
Anyone uses one of the Truffle languages in production? Like any Ruby or Python users are deploying on Graal's TrufflePython or TruffleRuby?
yes shopify runs on truffleruby. It is the fastest ruby VM by far and can seamlessly call state of the art Java libraries.
GraalVM is the VM to rule them all and unify currently incompatible billions of dollars libraries ecosystems.
Despite being the computer science breakthrough of the decade, people are not getting it yet.
> yes shopify runs on truffleruby
That's incorrect.
Shopify does not run on TruffleRuby.
I've always wondered if the perf silver bullet for Rails would be Graal/Tuffle.
I believe so. Especially with the possibility of optimizing across language barriers could mean that a C function can be inlined, resulting in possibly faster execution than native FFI.
The problem to my knowledge is that such a complex platform can even depend on some buggy side-effect down the line, so perfect interop is hard.
It doesn't seem like it. I think the newly added Ruby jit that you can optionally turn on is faster than Graal with a lot less startup time.