Delay in GraalVM 19.3 support - planned for Quarkus 1.2 - here is why
One of the highly anticipated features of Quarkus 1.1.0.CR1 was the GraalVM 19.3 support. GraalVM 19.3 changes quite a lot of things (JDK 11 preview etc) and due to the deep integration between Quarkus and GraalVM, it was an all-or-nothing update for us as we couldn’t support both GraalVM 19.2 and 19.3 at the same time.
While porting Quarkus to GraalVM 19.3, we hit several regressions, some due to Quarkus not doing the right thing (we fixed them), some due to GraalVM regressions (we are working hand in hand with the GraalVM team to fix them). The next micro bugfix release of GraalVM is planned for mid-January, so any workaround had to come from Quarkus and by writing substitutions.
Even if it wasn’t pretty, the end result was solid enough that we decided to ship CR1 with GraalVM 19.3 support.
And, yet, our 1.1.0.Final is back to GraalVM 19.2. It was a hard decision, believe us, especially with all the work invested to get things ready for 1.1. So why this step back?
We don’t want to break our promise
One of Quarkus promises is that the ecosystem works equally well on any JVM and as GraalVM native image executables. And you can build native images with no hassle on your side.
A number of issues were deviating from this line:
-
a concurrency issue striking randomly made the native image build fail sometimes
-
The Neo4J extension and more generally the Neo4J driver support no longer works in GraalVM 19.3: https://github.com/oracle/graal/issues/1995
-
a couple of Apache Camel Quarkus integration tests were no longer able to work in native image mode either due to https://github.com/oracle/graal/issues/1971. While we could have lived with the latter, it also means it could happen to any of your applications.
With these regression, we were already on the fence and already had taken some remediation (see below). But we found another one that is core to Quarkus promise.
RSS (memory) usage regression
After the 1.1.0.CR1 release, we got reports that our RSS usage numbers at startup were not as good as before. RSS measures the resident size of the process i.e. all the memory consumed by the process.
Our measures show Quarkus 1.1 with GraalVM 19.2 at 14MB after first request/response is served. And GraalVM 19.3 bumped it to 63MB. Because memory consumption for Quarkus is a core value, we decided to hit the revert button and take more time.
Investigations are happening between the Quarkus and the GraalVM team to remediate this. If you are interested in knowing more about it, see the Quarkus issue and its companion GraalVM issue. As soon as we get to the bottom of this one, the path to Quarkus on GraalVM 19.3 will be cleared.
So now what?
Well, first, be prepared to downgrade your GraalVM installation to 19.2.1 for the upcoming 1.1.0.Final.
We are full steam to bring GraalVM 19.3 support in our next release (and hopefully GraalVM JDK 11 support too). The concurrency issue is already fixed in GraalVM master, that lets us with the low-level issues. Our goal is to help the GraalVM team understand and fix these issues and get all of this backported to GraalVM 19.3.1.
But more fundamentally, we do not want that to happen again: discovering these late in the game is not fun. To be able to catch these issues earlier, we are setting up a set of CI jobs that will check that the whole Quarkus ecosystem (core extensions + quickstarts + Camel extensions + other external extensions) plays well with GraalVM master. This is a bit challenging as it’s (GraalVM) master on (Quarkus) master on (Apache Camel Quarkus) master, but that’s the only way forward. We have the CI job testing our QuickStart suite with Quarkus master and GraalVM master already.
We also plan to add some RSS usage checks to this CI pipeline. Funny story, we had a different CI job that was testing RSS but its report failed with a NPE. 🤦. Murphy when you hit us.
We hope you understand our cautious stance and the planned delay by a month or so.
In the meantime, a brand new Quarkus version is coming with a lot of exciting stuff so be prepared!
