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?
I'd love to just hear more about your experience building this on top of Graal/Truffle. Any interesting or surprising anecdotes?
> 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.
- 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.
- 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.
(edit: fix formatting and typos)
this article also goes into more details.
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.
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...
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.
What really amazed me is the second time the mouse moved over the toolbar, towards the end of the video, it lagged less and was able to recover to the 200+fps much faster than the first time.
BTW: GraalVM EE has support for profile-guided optimizations: https://medium.com/graalvm/improving-performance-of-graalvm-...