[Self-interest] future of the Self VM

Jecel Assumpcao Jr jecel at merlintec.com
Tue Aug 3 03:30:47 UTC 2021

This is a great discussion. I will make all my comments here instead of
in separate emails.

Right after I posted my original email I saw that I was wrong about
having to patch Cog to run Self. The difference between "selfSend x" and
"push self; send x" was important in Self 1 for two reasons: private
slots were ignored by the latter and the first allowed access to
temporary variables and arguments. But private slots became a user
interface only thing in Self 3 and local variables got their own
bytecodes in Self 4.1. So Smalltalk bytecodes are good enough though it
is a little awkward to handle resends.

The 1982 paper "Multiple Inheritance in Smalltalk-80" by Alan Borning
and Dan Ingalls uses the normal VM and their tricks would also work for


Another alternative would be to run Self in Javascript, like SqueakJS.
Note that on my machines and browsers SqueakJS is not as usable as it
seems to be for other people unless I use really old images (like mini
Squeak 2.2), but it does have many advantages. And my impression is that
the Javascript object model is more similar to Self's than to
Smalltalk's so the adaptation layer might be simpler.

Russell Allen:
> "Inverse Klein" idea: compile code to vector and run it

In Squeak there was the Exupery project by Bryce Kampjes that did just


Guillermo Adrián Molina used this technology to implement a complete
Smalltalk called Huemul.



Igor Stasenko created the NativeBoost project for Squeak/Pharo which
allows you to extend a method with native machine code and call that.


Randy Smith:
> Was this recorded? Would love to see it even post facto.

The previous UK Smalltalker's talks have been posted to:


They take a little while to edit and post them, but we will certainly
send a link to the video here as soon as it is available.

David Ungar:
> These days, I have gained a lot of respect for compiler support for immutability, and
> have been doing so much Swift programming, I might be tempted to see how tough
> a Self VM would be in that language. Just one more thing to throw into the stew of
> possibilities.

About constants, this is how I explain the advantages of adaptive
compilation. Whether something is immutable or not depends on the
timeframe we are talking about. Over decades nearly everything changes
while in a single clock cycle the whole memory of a Von Neumann computer
is constant except for a single word. So an ahead of time compiler will
have to treat as variable things that an adaptive compiler can treat as
immutable (with possibly the overhead of a check and recompilation if it
ends up changing).

Mario Wolczko:
> I feel duty-bound to have a go at making a Truffle implementation.

An AST-based Self would be pretty good, but I thought that bytecode
support had been added as part of the TruffleSqueak project? Anyway,
this was a great set of ideas!

Slava Pestov:
> bytecode interpreter?

The changes from the Self 4.0 to 4.1 bytecodes was meant to make an
interpreter more practical.

In 1997 I did a Self-in-Self implementation called tinySelf 1 (not to be
confused with tinySelf 0 which was a C program that parsed Self 3
sources but didn't do anything with them) and it was a bytecode
interpreter. It didn't implement primitives nor the memory system since
it used the underlying Self for those. The big deal was that each object
had its own thread, so it had a message queue and executed one message
at a time. That meant that any recursion would deadlock and this was an
experiment to work around that.


This was implemented in one afternoon, but I made two huge mistakes. The
first is that I implemented tail call optimization to allow more
parallelism but should have left this for a second version as it
eliminated information I needed to debug stuff. The second was that I
used many off the shelf Self objects like lists as dumb data structures,
so when I got bugs I couldn't patch them to find out where things were
going wrong because the whole system used them and would break if I made

Steve Dekorte:
> If a JIT is unnecessary, could WASM or JS be an implementation option?
> If so, it seems this would effectively allow everyone to use it regardless
> of platform via a single code base and target platform (the web browser). 

This would be a bit like the SelfJS option I mentioned above. My
impression is that WASM is still evolving and so this might be more
practical with future versions than the current one (implementing a
garbage colletor, for example).

Nathan Summers:
> A big issue is that there isn't a Windows port that supports the native
> windowing system. I was working on a port to SDL (which would double-duty
> for Windows and Android) when the machine I was using broke.

That sounds like a good idea. I think that the Mac version of Self uses
a library that is no longer supported, so SDL might be good for that as

When I was on the Squeak Oversight Board my job was to investigate ways
to improve the graphics. At the time the only reasonable options that
ran on the platforms we were interested in was embedded OpenGL, but that
is no longer true (things got worse with Apple moving to Metal).

-- Jecel

More information about the Self-interest mailing list