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?

> It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs, though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Truffle's approach? Or can Truffle realistically aim for the best of both worlds?

> One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?

I completely agree. Mario Wolczko, who worked on the Self VM at that time, is part of the extended GraalVM team. So the knowledge and experience is there, it only has to be implemented. The GraalVM team is thinking about ways to support snapshotting and a couple of other things. Their profile-guided optimizations [1] is probably the closest to that and definitely a way into the right direction. So I'd say it is possible to make performance of GraalVM languages much more predictable, maybe to the extent that it doesn't matter anymore for interactivity.

[1] https://medium.com/graalvm/improving-performance-of-graalvm-...

It would only if the test suite represents a realistic workload of your program.

BTW: GraalVM EE has support for profile-guided optimizations: https://medium.com/graalvm/improving-performance-of-graalvm-...

Thanks!

> I vaguely recall some mention in one of the docs I read a while back that you were having difficulties with the JIT causing noticable pauses/latency in interactive environments like Morphic, comparison to the OpenSmalltalkVM.

Right, have a look at the sub-discussion at https://news.ycombinator.com/item?id=24182587.

> Am I recalling correctly, and if so is it still the case?

GraalVM and TruffleSqueak have evolved quite a bit, but it is still the case. With libgraal, TruffleSqueak warms up much faster, and we were able to further improved the performance of TruffleSqueak. If you'd like to give it a try, it should be fairly easy to get started: https://github.com/hpi-swa/trufflesqueak#getting-started

> And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!

TruffleSqueak passes quite a lot of Squeak's SUnit tests (see [2]), but is of course not 100% compatible yet. Proper support for some plugins (e.g. FFI, OSProcess, ...) is still missing.

Apart from that, I'd say that TruffleSqueak has to live with the design decisions made in Truffle, but we can build on and reuse all of GraalVM components (e.g. JIT, GC, ...). The OpenSmalltalkVM, on the other hand, is more flexible, but you have to implemented everything from scratch.

[2] https://github.com/hpi-swa/trufflesqueak/runs/990481811?chec...

It does work with Cuis, but not with Pharo. The reason for this is that TruffleSqueak makes some assumptions about the layout of certain objects (e.g. instances of Class). Those assumptions no longer hold on Pharo, as it derived from the specification. Also, Pharo heavily uses FFI, which is not properly supported yet. Support for Pharo is not a priority, but contributions are welcome.

Yes, you can load recent, 64-bit, stock Squeak or Cuis images. Pharo is not (yet) supported. The user interface should be identical. For the polyglot API to work, some additional image-side code [1] needs to be loaded in your image.

[1] https://github.com/hpi-swa/trufflesqueak/tree/image

You can use TruffleSqueak for all languages supported by the GraalVM. Check out the demo videos at https://github.com/hpi-swa/trufflesqueak#demos.

Correct. We had to change the project name. Sorry for the confusion!

Correct, this indicates that recompilation occurred. The first time Graal compiled some of the UI machinery, which is all written in Smalltalk, no input events were triggered in the IDE. Consequently, the partial evaluator removed those code paths from compiled code. When we move the mouse over the window or start to click on UI elements, we cause recompilation, now with event handling compiled in. That's why these performance cliffs go away over time.

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...

> What is the main difference between this and other Smalltalk implementations besides the underlying GraalVM?

The implementation tries to be as compatible as possible. Apart from that, it's implemented using a language implementation framework (rather than from scratch), and written in Java (rather than in Smalltalk like the state-of-the-art OpenSmalltalkVM, or some low-level language).

> Is it that you can easily call to Java and JavaScript (and perhaps back)? > In other words, Why TruffleSqueak?

We are using TruffleSqueak as a research platform for polyglot programming. But, of course, it can do a lot more. The Smalltalk programming system runs on the same level as all other languages and on top of GraalVM. This allows direct interaction from Smalltalk tools with the GraalVM runtime. In the "Live plots with ggplot2" demo [1], for example, we briefly show a visualization of the Graal compilation queue. Usually, you'd have to go through something like JVMTI, but TruffleSqueak has direct access to the runtime.

I guess an alternative answer to your question is "why not?" :)

[1] https://twitter.com/fniephaus/status/1264839969115340800

thank you, kipply!

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.

- 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)

Author here. Happy to answer any questions!

> Can someone please give a sober explanation of what GraalVM, is and how Truffle works?

GraalVM is basically a JVM with a new compiler, the Graal compiler. Truffle is the language implementation framework for GraalVM and designed to build AST interpreter. The Graal compiler can optimize Truffle ASTs through partial evaluation (see "One VM to rule them all" paper [1]), and produces machine code directly without using Java bytecode as IR.

> how do JS semantics get expressed in a Java VM?

Graal.js comes with a parser for JavaScript code that generates a Truffle ASTs for a given JavaScript program. JS semantics are defined within the AST nodes (see [2]).

> What does a getProperty instruction look like?

I think getProperty is implemented in `CachedGetPropertyNode` [3], but I am not sure as there are multiple other property-related nodes.

> How does it know when to invalidate inline caches?

Unfortunately, Graal.js lacks documentation for `CachedGetPropertyNode`. But I encourage you to have a look at SimpleLanguage [4], a JS-like toy language and the reference language implementation for Truffle with proper documentation. [5] explains how reading properties and invalidating inline caches works and it's all done using the Truffle DSL. The `@Specialization` annotation [6] might be a good starting point if you want to learn how it works. You may also want to check out the docs on the GraalVM website (e.g. [7]).

[1] https://doi.org/10.1145/2509578.2509581

[2] https://github.com/graalvm/graaljs/tree/a36b978aa328a8da3a7f...

[3] https://github.com/graalvm/graaljs/blob/a36b978aa328a8da3a7f...

[4] https://github.com/graalvm/simplelanguage

[5] https://github.com/graalvm/simplelanguage/blob/a25e385dd8626...

[6] https://www.graalvm.org/truffle/javadoc/com/oracle/truffle/a...

[7] https://www.graalvm.org/docs/Truffle-Framework/user/README

Currently, you'd use the polyglot package that ships with the GraalVM SDK:

https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Con...

Here are a couple of demos:

https://github.com/graalvm/graalvm-demos

I said "currently", because you currently have to use the host Java, that is the Java on top of which all other languages are implemented. The GraalVM team is working on Project Espresso, a Java written in Truffle. That will make polyglot programming with Java much more consistent with the rest of the languages. Project Espresso isn't public yet, but here's the latest update from the team working on it:

https://github.com/oracle/graal/issues/1656#issuecomment-664...

If you're looking for an IDE for polyglot programming, GraalVM provides an extension for VSCode:

https://www.graalvm.org/docs/tools/vscode

and supports the LSP:

https://www.graalvm.org/docs/tools/lsp

You can do this with GraalVM. Here's an example: https://github.com/graalvm/graalvm-demos/tree/master/polyglo...

And here's a polyglot notebook example: https://fniephaus.com/2019/px19-polyglot-notebooks.pdf

And finally, here's our GraalVM-powered Jupyter kernel: https://github.com/hpi-swa/ipolyglot

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 [2] https://stefan-marr.de/papers/oopsla-marr-ducasse-meta-traci... [3] https://hal.inria.fr/hal-01596321/document

Thanks!

RE your question: Squeak's scheduler (also written in Smalltalk) would need to be extended with support for multi-threading. Since that requires a significant amount of work, it's probably out of the scope of the project at this point (unless someone is interested to work on this, of course). However, it's already possible to do multi-threading from Smalltalk using some other language like Java. We have some students doing just that with Ruby to parse HTML content in multiple threads.

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 [2] https://medium.com/graalvm/hpi-polyglot-programming-seminar-...

Thanks, glad you like it!

I'm not aware of anyone using GraalVM for its language interoperability in production. However, it's used by GraalVM languages internally for supporting things like C extensions and FFIs.

So far, there's been a lot of interest in the performance improvements that the Graal compiler provides [1] and GraalVM Native Image [2], the toolchain that allows the compilation of Java apps and Truffle languages into binaries.

But, there's a lot more you can do with GraalVM [3].

[1] http://www.ssw.uni-linz.ac.at/Research/Papers/Stadler14/Stad... [2] https://www.graalvm.org/docs/reference-manual/native-image/ [3] https://www.graalvm.org/docs/why-graal/

And there are other products based on GraalVM. For example, the Gluon Client plugins can compile Java apps to iOS (https://gluonhq.com/java-on-ios-for-real/) with GraalVM Native Image.

There are also a bunch of Java frameworks (e.g. Quarkus, Helidon, Micronaut; see "In the Highlights" section on the bottom of https://www.graalvm.org/ for more) that come with special support for GraalVM.

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

Yes, you're right. I've updated the diagram accordingly.

Oracle Labs is working on a Python3 implementation for the GraalVM: https://github.com/graalvm/graalpython

8 pronunciations of supercalifragilisticexpialidocious in English: https://youglish.com/search/supercalifragilisticexpialidocio...

Best result: https://www.youtube.com/watch?time_continue=2467&v=4axGm0g-1...

RE native runtime compilation: have you had a look at GraalVM's native image: https://www.graalvm.org/docs/reference-manual/aot-compilatio...

Have you had a look at GraalVM? Their native images [1] allow compilation of JVM-based languages into binaries with fast startup behavior and low memory footprint.

[1] https://www.graalvm.org/docs/reference-manual/aot-compilatio...