Graal “The Holy Grail” VM (Part I)
It’s been a while since i have written anything, and i am really disturbed today about something, so either i could just keep ruminating about what happened or find a way for a positive distraction, so thought well!, let’s do a medium post on something which has been fascinating me about the evolution of java runtime lately.
GraalVM — even the naming sounds like a some sort of LOTR sequel… perhaps right fully so.
I am not a big fan of java, primarily because its a very very verbose language, in the world of super idiomatic new comers like Kotlin and swift and dart and typescripts, Java is reeling to catch-up.
If you have written micro-services in java, you’d probably have used the ubiquitous spring boot framework for the dependency injection tricks, aah…. yes.. .DI… the quirky xml configs which define the beans, and packaging the Netty service into docker boxes, 1k LOC program ends-up as a 200meg bundle and has a cold start time of 5 seconds! (The go lang folks are laughing at a distance yes!)
Enter server-less, the above problem is even more pronounced, heck! it’s a deal breaker, 5 seconds to cold start the docker image + bootstrap time for the underlying docker runtime and what not, forget it!
I am like, dude! java is a dead horse in the world of Server-less! but thanks to some quick googling, i came across GraalVM, hmm… the name sounded scary at first, but i decided to dig deep.
So whats GraalVM, let me see if i can explain it like you are 5! (ELI5)
Traditional java programs are built and executed using a java virtual machine yeah? hmm… so you have
- The java byte code to execute
- The Java Virtual Machine
- The Platform (Linux or Mac or Windows)
So, what GRAAL does is that it creates 1 bundle combining the JVM + The java byte code, which runs natively on the underlying platform, meaning java code runs, at-least in principle, the same as C or C++ executable, how cool is that!
so…. whats the trick and what the catch?
Well, its how GraalVM builds the big fat executable in the first place, using a nifty technique called AOT (Ahead of time compilation), which as the name suggests, walks through the java executable and tries to resolve classes and their dependencies during build time!
Whats that!!
Hmm.. traditional java code, usually runs on this cool self-optimizing runtime called JIT or Hotspot VM, which does a lot of manipulatory acts, plugging and pushing objects out of memory, modulating life cycles, garbage collecting obsoletes, blah blah blah etc… this meant, java folks had a free hand to inventing more and more abstractions and jargons that go with it… the most ugliest of them being “Reflections!”
I am not like a pro java guy, but those who are - either swear by Reflections or hate it to death… (the good ones usually hate it, and avoid it completely)
Man! i am digressing… let’s come back to the rant on reflections later.
We were talking about AOT, AOT is the opposite of JIT (Just in time compilation), why? because with Graal, we don’t have a JVM anymore! so all those dynamic run-time optimizations with JIT tricks wont fly in Graal.
With Graal, you have to be able to walk through the dependency tree class by class as if. you are executing the code during compilation, which leads to a big fat executable, something which you can run on say unix like “~$./runner”.
If you are old school java folk, you’d probably be up in arms with the banner “Hey! whatever happened to write once run anywhere”…. but folks! folks! which rock were you living under in the past decade… haven’t you heard of containers?
Who needs a JVM + WORA anymore? just get the Graal executable bundle it with docker and docker runs anywhere, its docker once run anywhere now (DORA) ← i made that up just now! Cool right?
But the back pain in making this work is… yeah! you guessed it… Reflection-ismo!
Why? well this Reflections concept allows a class to invoke non-public methods of another class, thanks to JVM being a master manipulator at work.
But! GraalVM breaks down with reflections, with Graal, you have to be able to walk through the dependency tree class by class as if you are executing the code during build time, naturally the so-called non-public methods are not visible and this leads to whole bunch of build failures!
So, if you are dealing with a whole bunch of legacy code written by reflections kamikaze developers, you should probably stick to jvm, its not worth it…
But, lets say if its manageable, then you use this file called reflection-config.json and you specify which classes contain non-public methods and ask GraalVM compiler to not do a AOT on it…
Whaat! what good is that then?
Well.. like i said, only if there aren’t too many reflections, but the net performance gain coming out of GraalVM is orders of magnitude superior.
I can write a lot more about this, but for now i am starting to feel tired, so will continue in part II… but if you want to know how fast is GraalVM, in memory and run-time superiority over JVM, go to: www.quarkus.io and see just the pictures on the landing page (you can ignore everything else!!)
I am not going to proof read this write-up or anything! i intended it to be dirty and it turned out to be dirty… just free flow dump of thoughts.
But, i am actually feeling better after writing this…. :D :D so my primary objective is accomplished..
Part II: https://mohammedzu.medium.com/graal-the-holy-grail-vm-part-ii-9272fe144fbc