6 ms·

TruffleSqueak: Polyglot Programming with Squeak/Smalltalk and GraalVM

105 points by fniephaus 6y ago

fniephaus 6y ago
Author here. Happy to answer any questions!
- kjeetgill 6y ago
  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 6y ago
    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 6y ago
      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.
      - logicchains 6y ago
        > Only to grind to a halt as soon as the workload changed just a little, haha. 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.
        fniephaus 6y ago
        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.
        tinco 6y ago
        Would it help to for example run a full test suite on your project, and use the compilation results of that as a sort of base? I remember a long time ago C# had a feature like this.
        fniephaus 6y ago
        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-native-images-with-profile-guided-optimizations-9c431a834edb https://medium.com/graalvm/improving-performance-of-graalvm-...
- Rochus 6y ago
  I have somewhat lost track of the different versions. What is the difference between GraalSqueak and TruffleSqueak?
  - em-bee 6y ago
    i think it's just a rename with trufflesqueak being a newer version
    - fniephaus 6y ago
      Correct. We had to change the project name. Sorry for the confusion!
- russellallen 6y ago
  Its great to see this here. 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. Am I recalling correctly, and if so is it still the case? And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!
  - fniephaus 6y ago
    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 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 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?check_suite_focus=true#step:11:781 https://github.com/hpi-swa/trufflesqueak/runs/990481811?chec...
    - russellallen 6y ago
      Cool. That video of the bouncing atoms demo is fascinating. It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs[1], though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Tuffle'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? [1] https://bibliography.selflanguage.org/_static/third-generation.pdf https://bibliography.selflanguage.org/_static/third-generati...
- em-bee 6y ago
  i saw mention of cuis, but i could not see anything about pharo. does this work with pharo?
  - fniephaus 6y ago
    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.
    - fniephaus 6y ago
      s/derived/deviated/
- em-bee 6y ago
  how deep does the support go? can i load an existing squeak/cuis/pharo? image? or is it only code compatible in that i can copy code from supported languages? as a squeak or cuis user do i see any difference on the interface or is it all under the hood with additional APIs available that i can access from my code?
  - fniephaus 6y ago
    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 https://github.com/hpi-swa/trufflesqueak/tree/image
- em-bee 6y ago
  what about the support for other languages from trufflesqueak? i saw mention that objects can be shared, but can i write code in other languages? can i use trufflesqueak as my IDE to write python or ruby?
  - fniephaus 6y ago
    You can use TruffleSqueak for all languages supported by the GraalVM. Check out the demo videos at https://github.com/hpi-swa/trufflesqueak#demos https://github.com/hpi-swa/trufflesqueak#demos.
- galaxyLogic 6y ago
  What is the main difference between this and other Smalltalk implementations besides the underlyiing GrallVM? Is it that you can easily call to Java and JavaScript (and perhaps back)? In other words, Why TruffleSqueak? (I didn't see a good answer to that on the website)
  - fniephaus 6y ago
    > 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 https://twitter.com/fniephaus/status/1264839969115340800
    - galaxyLogic 6y ago
      Awesome
kipply 6y ago
yay this is great! <3
- fniephaus 6y ago
  thank you, kipply!
em-bee 6y ago
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
anton96 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.ecoop.org/details/ecoop-2020-tutorials/1/Polyglot-Programming https://web.archive.org/web/20200319123703/https://2020.ecoo...
    - radiowave 6y ago
      One of the problems with attempting to propagate Smalltalk culture is that when your interaction with the machine doesn't resemble interacting with a teleprinter, then a wall of text becomes a poor medium for capturing it. Not disputing that video brings its own problems.
- soapdog 6y ago
  I think the bias towards videos is because of the interactive and graphical nature of Smalltalk. Other programming languages, a simple text post with code snippets is usually enough but, with "environments full of awe and wonder" such as Squeak I believe only video can fully capture what is going on.

105 points by fniephaus 6y ago

fniephaus 6y ago

Author here. Happy to answer any questions!

kjeetgill 6y ago
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 6y ago
  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 6y ago
    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.
    - logicchains 6y ago
      > Only to grind to a halt as soon as the workload changed just a little, haha. 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.
      - fniephaus 6y ago
        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.
        tinco 6y ago
        Would it help to for example run a full test suite on your project, and use the compilation results of that as a sort of base? I remember a long time ago C# had a feature like this.
        fniephaus 6y ago
        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-native-images-with-profile-guided-optimizations-9c431a834edb https://medium.com/graalvm/improving-performance-of-graalvm-...
Rochus 6y ago
I have somewhat lost track of the different versions. What is the difference between GraalSqueak and TruffleSqueak?
- em-bee 6y ago
  i think it's just a rename with trufflesqueak being a newer version
  - fniephaus 6y ago
    Correct. We had to change the project name. Sorry for the confusion!
russellallen 6y ago
Its great to see this here. 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. Am I recalling correctly, and if so is it still the case? And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!
- fniephaus 6y ago
  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 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 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?check_suite_focus=true#step:11:781 https://github.com/hpi-swa/trufflesqueak/runs/990481811?chec...
  - russellallen 6y ago
    Cool. That video of the bouncing atoms demo is fascinating. It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs[1], though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Tuffle'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? [1] https://bibliography.selflanguage.org/_static/third-generation.pdf https://bibliography.selflanguage.org/_static/third-generati...
em-bee 6y ago
i saw mention of cuis, but i could not see anything about pharo. does this work with pharo?
- fniephaus 6y ago
  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.
  - fniephaus 6y ago
    s/derived/deviated/
em-bee 6y ago
how deep does the support go? can i load an existing squeak/cuis/pharo? image? or is it only code compatible in that i can copy code from supported languages? as a squeak or cuis user do i see any difference on the interface or is it all under the hood with additional APIs available that i can access from my code?
- fniephaus 6y ago
  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 https://github.com/hpi-swa/trufflesqueak/tree/image
em-bee 6y ago
what about the support for other languages from trufflesqueak? i saw mention that objects can be shared, but can i write code in other languages? can i use trufflesqueak as my IDE to write python or ruby?
- fniephaus 6y ago
  You can use TruffleSqueak for all languages supported by the GraalVM. Check out the demo videos at https://github.com/hpi-swa/trufflesqueak#demos https://github.com/hpi-swa/trufflesqueak#demos.
galaxyLogic 6y ago
What is the main difference between this and other Smalltalk implementations besides the underlyiing GrallVM? Is it that you can easily call to Java and JavaScript (and perhaps back)? In other words, Why TruffleSqueak? (I didn't see a good answer to that on the website)
- fniephaus 6y ago
  > 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 https://twitter.com/fniephaus/status/1264839969115340800
  - galaxyLogic 6y ago
    Awesome

kipply 6y ago

yay this is great! <3

fniephaus 6y ago
thank you, kipply!

em-bee 6y ago

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

anton96 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.ecoop.org/details/ecoop-2020-tutorials/1/Polyglot-Programming https://web.archive.org/web/20200319123703/https://2020.ecoo...
  - radiowave 6y ago
    One of the problems with attempting to propagate Smalltalk culture is that when your interaction with the machine doesn't resemble interacting with a teleprinter, then a wall of text becomes a poor medium for capturing it. Not disputing that video brings its own problems.
soapdog 6y ago
I think the bias towards videos is because of the interactive and graphical nature of Smalltalk. Other programming languages, a simple text post with code snippets is usually enough but, with "environments full of awe and wonder" such as Squeak I believe only video can fully capture what is going on.