I have a copy of this on my bookshelf. I highly recommend reading the portion of the book about the structure of the object memory. An interesting approach that influenced much of what we have today in VMs, with one notable exception.
In Smalltalk there was no filesystem, so the canonical representation of the system was in memory at all times while the system was booted. It dumped and restored this object memory on shutdown and boot. Its structure also allowed for automated refactoring at a semantic level (objects knew who their callers were) which is something no other language I've ever used is capable of.
> Its structure also allowed for automated refactoring at a semantic level (objects knew who their callers were)
It isn't quite as magical as that. It's somewhat better than most dynamic languages when refactoring and probably had the first refactoring browser. There were versions where you can run scoped refactoring like restricting method renames to within a class hierarchy or package.
> In Smalltalk there was no filesystem, so the canonical representation of the system was in memory at all times while the system was booted. It dumped and restored this object memory on shutdown and boot.
There was a lot of work on virtual memory for Smalltalk, where objects could be paged in and out of memory, but i don't think it was ever in any version i actually used:
Maybe the stuff in the endlessvoid94's second paragraph: Its structure also allowed for automated refactoring at a semantic level (objects knew who their callers were) which is something no other language I've ever used is capable of.
In Smalltalk there was no filesystem, so the canonical representation of the system was in memory at all times while the system was booted. It dumped and restored this object memory on shutdown and boot. Its structure also allowed for automated refactoring at a semantic level (objects knew who their callers were) which is something no other language I've ever used is capable of.