Recap of Virtual Meetup on GraalVM (part 1 & 2)

Yesterday we had a great meeting on GraalVM, presented by @Niko

It was a great meeting which sparkled a lot of interest. Thank you to everyone who joined!

In the chat we exchanged a lot of useful resources.

Here they are.

On Twitter using GraalVM

Graal & Truffle to write JVM interpreters

List of resources on Graal(VM)

GraalVM to write MPS-based interpreters

Some information on using Truffle:

Motivations for Truffle DSL:

Luna, a language using Truffle


Another interesting (but old) article on Truffle:

Recent tutorial by Nicolas Laurent on Truffle:

On AST vs. Bytecode: Fabio Niephaus’ paper compares AST-based :


Thank you for the recap
I couldn’t join but fortunately found this useful post

1 Like

We had a great second meeting on GraalVM.

Native images

@rafael asked if exception stack traces look different and @fniephaus replied that yes they do. He also said that RedHat people are adding more debug info, so you can see Java stack frame info more or less from within GDB. Here there are some related PRs:

@neomatrix369 shared this link: It is an example to convert Jar into Native Image

Starting point for native image:

And here a description of the limitations:

And specifically on reflection:

@neomatrix369 also suggest to look for the .md files in here . There you should find docs on the individual aspects of java config and how to handle them like JNA/JNI etc…

Article that covers also native image:


Article on running Java inside a Jupyter Notebooks using GraalVM (java 11 or higher)

Espresso is an implementation in Truffle of Java. You can find more about it here:

Regarding Espresso, @rafael points out this

We’re currently working on making Espresso 100% TCK compliant (about 1% to go). Soon after that, we plan to open source it.

Tool support

@fniephaus GraalVM comes with an extension for VSCode with support for the LSP…the integration is built on top of the instrumentation API:


@chrisseaton pointed out that you can also parse binary files and he has also generated an AST without going through any serialised format

Other stuff

You should subscribe to the GraalVM slack. Get an invitation here:

I shared the link to an RPG interpreter which we co-developed and is open-source:

1 Like

Thinking again about Truffle, I was wondering how this “specialization via annotations” approach compares to generating Java source code (using whatever method available) then compiling it for the GraalVM or any other VM. The point is, when generating Java source code, you have to resolve all specializations anyway.

The flow is more complex, since you have to generate an intermediate representation as source code rather than work directly on the AST. But this have some advantages as well, such as easier debugging.

Any thoughts ?

1 Like

But how would be the information for generation be provided? I think it is useful to have it in a source connected to the code of the interpreter, as they seem strongly related

1 Like