Bootstrapping "Optimizing Squeak"

Dan Ingalls DanI at
Fri Feb 26 16:43:53 UTC 1999

>I have been reading the "Optimizing Squeak" thread with great interest,
>though not always with great understanding :-)  Playing with different VM
>architectures and alternative bytecodes sounds like enormous fun and a
>really powerful student project.
>How does one actually move to a new bytecode set?  What is the path by
>which you say "Okay, recompile all the code in the system using my new
>compiler in order to create a new image for my new VM"?  The Digitalk
>people had to do this at least once, didn't they?  Or do new bytecode sets
>typically retain some backward compatibility while bootstrapping?

Mark -

There are a couple of ways to do this.  If there is room for the new bytecode(s) with the old, you build a new VM that supports the new, change the compiler to compile it, and recompile all methods in the system.  I did this when making the extensions so Squeak could address 256 literals in a method and 256 named instvars in an object.  If this frees up the old bytecode(s), then you can remove the code for the old bytecode from the VM after the recompilation.

For more radical changes, we use the SystemTracer.  This writes a clone of a running (!) image onto the disk.  Since it is just writing a file it can make arbitrary transformations on the way to disk.  This is how we changed Squeak from an object-table to the current direct-pointer object memory format.  More recently Tim Rowledge's change to the format of compiled methods was done this way.  Having written the new image, it's a small matter of rewriting and debugging the VM until can run the new image.

	- Dan

More information about the Squeak-dev mailing list