GraalVM new "Espresso" -- viable for an improved dev experience w/ HotSwap API + enhanced debugging/monitoring?

Description

I’m sure the Quarkus folks are well aware of it, but Graal has recently released their new Espresso framework which implements Truffle for JVM bytecode

• https://www.graalvm.org/reference-manual/java-on-truffle/

This brings several advantages and unique abilities that I think would be beneficial to the Quarkus userbase.

• (It also has some disadvantages – notably that the running in this mode suffers from a several-fold reduction in performance currently)

It seems like like greatest benefits for Quarkus apps would be:

• The integration with the suite of tools that GraalVM has for Truffle languages. The automatic code-coverage tool, deep profiling + observability that comes built in, plus a few other things

• The enhanced HotSwap API. Quarkus already has Dev Mode and Compilation Providers which do a solid job of providing live-reload functionality.

  • It may be possible to push the envelope here and bring the reload times into “Supersonic” speeds ;^)
  • This would be awesome.

• As mentioned above, it’s actually possible to compile to a native image but retain dynamic functionality because the bytecode is being interpreted.

  • You’d suffer a performance penalty from this, but it may open the door to things like full Groovy support in Quarkus, or other general functionality which otherwise wouldn’t be possible at all (or incredibly difficult) in a native image.

---

The default extended HotSwap capabilities of Espresso (IE, you don’t need to do anything to enable them) covers many things but for framework-specific behavior or annotations etc, this requires a plugin.

There’s an example integration with Micronaut which is quite brief (50 LOC) here:

• https://www.graalvm.org/reference-manual/java-on-truffle/hotswap-plugin/#micronaut-hotswap-plugin

I’m not sure if this is useful given how different Quarkus and Micronaut are in terms of architecture + internals but I figured I would share just in case.

Implementation ideas

If this is viable or useful at all to have in Quarkus, maybe someone could share a rough outline of what the HotSwap plugin would need to do/look like, and (time permitting) I may be able to take a stab at it.

The other thing would probably be a guide on how to configure running in Espresso mode in your Maven/Gradle builds, assuming the user is running on GraalVM’s JDK.

[gilles-duboscq]

I am not sure I get this part, but I might be missing something. To my understanding one can essentially compile Espresso to a native image, not their application running on top of Espresso. So I don’t see how this is any different from running a Quarkus application on HotSpot.

To clarify on what espresso offers exactly there: it is possible to embed espresso into any native-image and use it to load and run bytecodes. It works in the same way that it’s possible to embed the GraalVM JavaScript implementation into any native image.

The result is that you have 2 JVM environments in the same process: “host Java” that runs in HotSpot or pre-compiled as a native-image, and “guest Java” that runs in espresso. You can use the polyglot API to call one from the other. It’s not as seamless as if it was just one environment but it would allow things such as a main application running in host Java with guest Java plugins.

There is one example here with jshell: the shell and compiler are part of the pre-built native image while the code that’s dynamically entered by the user is run on espresso.

That said, since I don’t know Quarkus well, I don’t know exactly how it would apply there.

[GavinRay97]

Sorry for slow reply @zakkak

Given that Quarkus already supports live-reload, I am afraid any benefit from Espresso’s hot swapping would be offset by its runtime overhead.

This is a fair question, let me ask some of the folks that worked on this area of Espresso specifically. I’m not that knowledgeable either, to be honest.

My understanding was that:

• “Normal” Java/JVM langs already have HotSwap capabilities
• These HotSwap capabiltiies have many limitations
• Because Espresso runs Java/JVM code as if it were a “guest” language (such as JS/Python/Ruby), the Graal team was able to build a set of HotSwap API’s that were much easier to write + use than the existing ones, and which have fewer limitations since you “control” the entire context of the guest

To my understanding one can essentially compile Espresso to a native image, not their application running on top of Espresso. So I don’t see how this is any different from running a Quarkus application on HotSpot.

Because Espresso is dynamic guest-language context (it’s JVM bytecode, implemented as another Truffle language), you can run dynamic code on it – EVEN if the host binary is running on a native image.

One useful example for Quarkus:

• I wrote a Groovy extension which works in JVM mode, and nearly works in native-image but not quite
• If it were running on Espresso in a native image, it would work entirely because I could use all the dynamic code of Groovy

You aren’t limited by statically analyzeable callsites anymore. What runs on the native image is essentially a JIT, but that has the startup time of a regular native image.

So you pay the price of reduced performance but it re-enables dynamic behavior and can enable scenarios which would otherwise have been impossible (IE Groovy-based native-image Quarkus)

• You might ask “What the hell is the point of that?”, and the one scenario I can think of is if someone really wanted to use Groovy for Serverless Quarkus. Espresso running on a Native Image JIT’ing/interpreting the Groovy code would make the launch time acceptable for this sort of workload.

---

That being said, I DO think the real value for Quarkus lies in it being used during development, because it opens the entire Truffle suite of tooling and profiling applications with zero changes to a codebase. And in development, losing x2-3 performance on an app doesn’t matter.

I also think that the HotSwap API’s may be able to make Quarkus Devmode even faster than it is currently, because no compilation has to be done, but I need to double check on this.

Will speak to the Graal Folks and get back on this