
Smalltalk with the GraalVM - mpweiher
https://www.javaadvent.com/2019/12/smalltalk-with-the-graalvm.html
======
pron
Just a clarification: when used as a JIT, Graal does not compile languages
defined with the Truffle framework into Java bytecode. Rather it compiles
_both_ Java bytecode and Truffle languages _directly_ into machine code (in
this case, the Truffle language is Smalltalk bytecode), which it then installs
in Hotspot's code cache. The diagram places the Graal compiler above Hotspot
when it would be more appropriate to place it as a component inside of
Hotspot, where it replaces the C2 compiler (Java bytecode to machine code), as
well as directly compiles Truffle languages into machine code.

Graal can also be used as an AOT compiler ("GraalVM Native Image") -- from
Java bytecode (only!) to a native executable that runs independently of
Hotspot. If the Java program so compiled is itself a Truffle interpreter, the
result is a native interpreter for the Truffle language, that contains an
optimizing JIT (for the Truffle language only).

To make things even more interesting, when Graal is used as a Hotspot JIT,
because Graal itself is written in Java, it must either compile itself
(bootstrapped by Hotspot's Java bytecode interpreter) -- in which case it is
both a Java component run _by_ Hotspot as well as a component _of_ Hotspot --
or it could be AOT-compiled into a native shared library, which is then loaded
by Hotspot like any other shared library.

~~~
walkingolof
As of Graal 19.1 , libGraal, a pre-compiled C2 JIT compiler, is bundled with
GraalVM.

You can use it by adding the following JAVA_OPTS:

-XX:+UseJVMCICompiler -XX:+UseJVMCINativeLibrary

~~~
chrisseaton
> libGraal, a pre-compiled C2 JIT compiler, is bundled with GraalVM

libgraal isn't a C2 JIT compiler - it's (the clue is in the name here) a Graal
compiler.

And the person you're replying to already mentioned it:

> or it could be AOT-compiled into a native shared library, which is then
> loaded by Hotspot like any other shared library

------
radiowave
The embedded video showing a Smalltalk inspector being used to examine Python
objects - that put a big smile on my face.

~~~
fniephaus
Happy to hear that! If you'd like to see some Smalltalk tools rendered in Java
Swing, check out this demo [1]. More details on this are in the blog post on
our Polyglot Programming seminar [2].

[1]
[https://www.youtube.com/watch?v=If7xNBYA0Bk](https://www.youtube.com/watch?v=If7xNBYA0Bk)
[2] [https://medium.com/graalvm/hpi-polyglot-programming-
seminar-...](https://medium.com/graalvm/hpi-polyglot-programming-
seminar-3fd06ffa59d2)

------
fniephaus
Hi everyone, I'm the author of the blog post. Feel free to let me know if you
have any questions or suggestions!

~~~
Rochus
That's interesting work, thank you very much. I would be very interested in
the performance gain in using the GraalVM JIT compared to the original Squeek
(Cog) or e.g. VisualWorks the performance of which is comparable to CPython
([https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html)). I'm
aware of another publication which concludes that the performance gain of a
Truffle based solution is about the same as of an RPython based one. Did you
also have a look at this? And finally: could'nt you improve performance even
more by using a more optimized bytecode (instead of the bluebook one, as it
was e.g. done here
[http://strongtalk.org/downloads/bctable.pdf](http://strongtalk.org/downloads/bctable.pdf))?

~~~
fniephaus
We compared the runtime performance of GraalSqueak with OpenSmalltalkVM
(formerly Cog) and RSqueak (RPython-based VM) in Figure 4 of our MPLR’19 paper
[1] for the first time. Since then, we've worked on a couple of performance
optimizations. So at the moment, I think GraalSqueak is only slower in the
DeltaBlue benchmark... in all others, it's (often significantly) better than
OpenSmalltalkVM. However, please also note its limitations which we discussed
in section 5.2, especially with regard to Smalltalk's interrupt handler and
Partial Evaluation performed by the Graal compiler.

So far, I'd say our observations wrt RPython match the ones discussed in
"Tracing vs. Partial Evaluation" [2]: Language implementers have to do more
work in Truffle, but probably get better peak performance in return (not
talking about warmup or memory consumption here).

RE "a more optimized bytecode" set: Sista [3] (an extension of the
OpenSmalltalkVM) is doing something like that, too. I'd guess performance
would be more or less the same using GraalVM as Truffle produces highly
specialized code. But, of course, this would need to be benchmarked. The
advantage of the Sista approach is that it's managed on the image level, so
specialized versions of methods are persisted as part of the image. AFAIK the
GraalVM team is working toward persisting compiled code caches, which is kind
of similar but on the level of the language implementation framework.

Hope this answers your questions!

[1]
[https://fniephaus.com/2019/mplr19-graalsqueak.pdf](https://fniephaus.com/2019/mplr19-graalsqueak.pdf)
[2] [https://stefan-marr.de/papers/oopsla-marr-ducasse-meta-
traci...](https://stefan-marr.de/papers/oopsla-marr-ducasse-meta-tracing-vs-
partial-evaluation/) [3]
[https://hal.inria.fr/hal-01596321/document](https://hal.inria.fr/hal-01596321/document)

~~~
Rochus
Thank you for your detailed, interesting answer. I look forward to reading the
referenced papers. At the moment I am building frontends for LuaJIT and would
like to compare performance with analog implementations in RPython and
Truffle. Maybe I will build a Smalltalk-80 frontend and then compare it to
your mentioned implementations.

------
azinman2
Is Graal finally there? Years ago there was a lot of promise that it would be
THE “one true VM” that allowed python and ruby to fly. But I don’t really hear
much about it on those fronts. Where are we at?

~~~
txdv
Twitter is using it, they are seeing gains of 10% for Scala.

It is a big project, there are many runtimes it supports, it already seems
production ready.

