[Self-interest] future of the Self VM

[Jecel Assumpcao Jr]

Russell's talk this past Wednesday was really great! I liked the idea of
starting of with a demo building a slide viewer to use for the rest of
the talk.

One of the slides was about options for moving the VM forward. I
remember at least some of the alternatives - please add any that I
forgot.

I would mention that a very significant reason Self never became popular
was that it didn't run on machines people had (a problem shared with
nearly all the Unix clones that came before Linux). This was why many
people wrote their own Self variations or Self inspired languages in the
early days. I actually bought a Sun Ultra 5 machine in 1998 (the most
money I have spent in my life so far) so I could continue to use Self
after I moved away from the University. Just a few years later with Self
running on PowerPC Macs and later x86 Macs and Linux machines people
could finally try Self. Sadly, they didn't because of the silly idea
that only things coming out right now are worth looking into. With
everybody moving to x86-64 and now also Apple ARM we are back where we
started! So how do we fix this?

    - changing the C++ VM to handle 64 bits and target the currently
popular processors

During the talk I mentioned the lack of progress in the StrongTalk VM as
an example of how hard this is because you need developers who both like
C++ and Smalltalk/Self. I was a nice surprise to be contradicted by
George Cox who said he is actually working on StrongTalk:

https://github.com/gjvc/strongtalk-2020

The move from 32 bits to 64 bits in Squeak happened twice (first at HP
and then with Eliot Miranda). That wasn't an absurd amount of work and
even though there was some advantages in using Slang instead of C++ it
is likely to be doable for the Self VM. Adding x86-64 to a compiler that
already can generate x86 code is another reasonable project. Supporting
the ARM64 would require a larger effort.

    - do a Graal/Truffle implementation

While I have no more interest in programming in Java than in C++, this
is actually an interesting option. The TruffleSqueak project had nice
results for (I might be wrong) a student-level effort. And with their
Polyglot project the various languages can work together in a very nice
way.

I think partial evaluation will be an important technology in future
compiling VMs, but I don't know enough about Graal to evaluate this
alternative.

    - patch OpenSmalltalk VM (Cog) used for NewSpeak, Squeak, Pharo and
Cuis to support Self

This is something that I strongly recommended to the Slate guys even
before Cog. I showed how a little tweak would allow multiple dispatch to
be added to the VM. Many things needed to support prototypes (maps
instead of classes, for example) don't actually make a difference at the
VM level and so would require no changes. The way closures are handled
in Cog and in the Self 4.1 bytecodes (previous Selves used message
passing instead) are very different and Self needs to distinguish
between implicit self sends and sends to "self". Resends a slightly more
tricky than super.

Recently Cog has implemented support for multiple bytecode sets in the
same image in order to support Sista. Note that Cog itself is a dynamic
compilation system and it is the addition of Sista that makes it an
adaptive compiler more comparable to the Self VM. While there is VM
support for Sista in the form of an alternative bytecode set it mostly
exists in the image and so wouldn't help a Self system running on Cog.

    - Klein

The OOPSLA 2005 paper on Klein (available to ACM members) include the
video fo the talk by David Ungar, Alex Ausch and Adam Spitz (available
to everyone):

https://dl.acm.org/doi/10.1145/1094855.1094865

One interesting thing in the talk was showing both Klein running inside
Self (like the Squeak Simulator) as well as running on a separate
computer (making it a SqueakNOS). I think it is a very interesting
project that could be extended in worthwhile directions (like running on
top of an operating system for those who like that sort of thing and
handling multiple processors like the RoarVM).

My first impression when trying to browse through Klein code was of some
confusion. I soon found out that many of the methods I was looking at
had been generated and that I needed to look at the sources for them
instead. Is this actually the case? It was a while ago so I might be
remembering it wrong.

    - inverse Klein

I have no idea what this means.

-- Jecel