
TruffleSqueak: Polyglot Programming with Squeak/Smalltalk and GraalVM - fniephaus
https://github.com/hpi-swa/trufflesqueak
======
anton96
It sounds very interesting but I don't understand the obsession of the
smalltalk community with videos, it makes it impractical to get more info.

~~~
fniephaus
Personally, I like watching good demo videos of systems I am not familiar
with, and not everyone is familiar with Smalltalk. It's easy to set
TruffleSqueak up on your machine if you like to experiment on your own. Apart
from that, the README.md includes a list of blog posts and papers.

Anyway, I'd really like to know how we could improve and make it more
"practical to get more info". Any thoughts or suggestions?

~~~
anton96
It's very nice to have videos and that must be a lot of work!

It's just that I like having those good old tutorials with text an few
screenshots.

~~~
fniephaus
Thanks for the feedback! We have plans to create a tutorial soon and run it
virtually during SPLASH/ECOOP'20 [1] (I have to check why the tutorial page is
no longer public).

[1]
[https://web.archive.org/web/20200319123703/https://2020.ecoo...](https://web.archive.org/web/20200319123703/https://2020.ecoop.org/details/ecoop-2020-tutorials/1/Polyglot-
Programming)

------
fniephaus
Author here. Happy to answer any questions!

~~~
kjeetgill
Ever since Graal was opensourced I've been nothing short of mesmerized by all
of the amazing work being done on/with it.

I'd love to just hear more about your experience building this on top of
Graal/Truffle. Any interesting or surprising anecdotes?

~~~
fniephaus
Thanks!

> I'd love to just hear more about your experience building this on top of
> Graal/Truffle.

There are lots of good resources for learning how to implement a language in
Truffle. In addition to the official documentation and the GraalVM Slack, I
often find myself looking at other GraalVM languages that are open source
(e.g. Graal.js, SimpleLanguage, GraalPython). Also, the tooling available to
language implementers is quite good (e.g. all debugging and profiling tools
for Java, Truffle's language-agnostic tools, Ideal Graph Visualizer for
analyzing Graal/Truffle graphs, Graal/Truffle command-line flags, ...).

> Any interesting or surprising anecdotes?

Supporting a Smalltalk system on the GraalVM definitely comes with interesting
challenges, here are a couple of examples:

\- Truffle is designed for building AST interpreters. Squeak is based on the
Smalltalk-80 specification, which includes a well-defined bytecode set. For
compatibility, you want a bytecode interpreter for Smalltalk. We even wrote a
paper about how to do this with Truffle:
[https://fniephaus.com/2018/icooolps18-graalsqueak.pdf](https://fniephaus.com/2018/icooolps18-graalsqueak.pdf).

\- Implementing some core Smalltalk mechanisms (e.g. allInstances,
thisContext, becomeForward:, ...) and make them work well with the Graal
compiler.

\- Smalltalk is not just a language, but also a programming system.
TruffleSqueak uses AWT/Swing for rendering the UI on GraalVM, and SDL2 when
AOT-compiled with native image. Running UI applications with the Graal
compiler, however, can yield interesting results. See for yourself:
[https://www.youtube.com/watch?v=wuGVyzUsEqE](https://www.youtube.com/watch?v=wuGVyzUsEqE).

\- Saving the image without breaking compatibility with the OpenSmalltalkVM
and other Smalltalk VMs.

\- Most languages are file-based, so Truffle's APIs are designed for files. In
Smalltalk, everything -- even code -- is an object.

Let me know if you have any follow-up questions. You may also find our paper
on TruffleSqueak (formerly GraalSqueak) an interesting read:
[https://fniephaus.com/2019/mplr19-graalsqueak.pdf](https://fniephaus.com/2019/mplr19-graalsqueak.pdf).

(edit: fix formatting and typos)

~~~
kjeetgill
That bouncing atoms video just blew my mind. It took whole minutes, but it got
so incredibly fast... Only to grind to a halt as soon as the workload changed
just a little, haha.

I'd imagine you have a ton of bigger priorities, but being so hackable I
wonder if there are easy tools within Graal/Truffle to hit that peak
performance sooner and be stabler. I'd never expected it to stall so
aggressively, probably worse than full GC.

Still, blown away.

~~~
fniephaus
The Graal compiler is known to be slow in terms of warmup. At the same time,
it provides great peak-performance. However, and as you can see in the video,
partial evaluation will trigger recompilation if the program is not "stable".
And when you're interacting with an IDE, it will take quite some time for the
IDE to become stable. Even worse, some things like debugging sessions will
never be stable.

Of course, it doesn't make much sense to run your IDE at +60FPS. Squeak
usually throttles the frame rate, and then the performance cliffs are harder
to notice.

Nonetheless, the GraalVM team is very much aware of these problems and is
actively working on them. We are only the first to visualize this in the form
of an IDE. A couple of GraalVM releases ago, they introduced libgraal [1],
which improved compilation times significantly. One idea to make this even
better is to persist compiled code from the JIT, so that it can be reused the
next time you run the program/IDE. Morphic, Squeak's UI framework, is unlikely
to change and could be warmed up in advance.

[1] [https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-
pr...](https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-precompiled-
graalvm-native-image-26e354bee5c)

~~~
grashalm
Truffle team lead here. Yes we are working full steam on improving warmup and
delays caused by going back to the interpreter in unexpected cases. Expect
bigger improvements in this area soon.

That being said, we cannot do it all on the Truffle side without help of the
language implementation. Truffle languages speculate on certain aspects of the
program data. If they do so, then we need to deoptimize and invalidate the
optimized code when this speculation is violated. So the stability of the
language implementation really is an important factor. Questions like "do we
need to speculate on this value being constant or does give us enough benefit
to justify the deoptimization overhead?" need to be answered by the language
implementation and not the Truffle framework. Afaik this was not a priority
for TruffleSqueak so far, but it might be in the future. So there are
potentialy future improvements also on the TruffleSqueak side.

~~~
kjeetgill
I had no idea speculation was surfaced up through Truffle. That's so cool.

~~~
grashalm
Well, it is necessary to expose this to language implementations to reach good
performance. If we could reach the same performance otherwise, we would not
expose it, as it makes implementing Truffle languages more complicated.
Unfortunately automating the specializing part is an unsolved research
question for a method based compiler (deserves its own PhD). Other trace based
meta-compilation approaches (e.g. PyPy) have an advantage here, but
disadvantages in other areas.

------
em-bee
previous discussion about trufflesqueak:

[https://news.ycombinator.com/item?id=21735782](https://news.ycombinator.com/item?id=21735782)

and a general discussion of the graalvm from last week:

[https://news.ycombinator.com/item?id=24103233](https://news.ycombinator.com/item?id=24103233)

------
kipply
yay this is great! <3

~~~
fniephaus
thank you, kipply!

