Bootstrapping "Optimizing Squeak"
DanI at wdi.disney.com
Sat Feb 27 23:09:20 UTC 1999
>this idea came to me a few minutes ago: how hard would it be, and what kind
>of performance penalty would you have to pay to make the bytecode set a
>property of a method such that the vm would execute different methods
>against different bytecode sets? specifically, i'm thinking it would be
>great to have the vm be able to run both the smalltalk bytecode set and the
>java bytecode set. sure, optimally you would have one universal vm bytecode
>set, but i think i nice intermediate step would be to be able to use both
Yes, this is a useful approach.
The way to evolve is to facilitate variety -- natural selection will take its toll.
One of the simplest ways to do this is to assume that every method is native code. Then every method that is bytecoded can begin with a jump to its interpreter -- not a bad overhead to pay. Obviously multiple interpreters could be handled trivially in this manner, and native methods can be included de facto with almost no overhead.
It was part of our original design for Smalltalk that the interpreter is associated with the class of the receiver -- in fact that the class BE the interpreter for its instances. Thus the receiving object passes itself to its class, along with the selector and arguments for interpretation. This allows different classes to have different structures for method dictionaries and inheritance, as well as methods. Obviously there has to be some consistency within inheritance structures.
Why didn't we explore this avenue of flexibility? I think partly because everything came out so cleanly on the first serious go-round that we were lured into the simplicity of a single model. I think it would be fun to revisit the variant interpreter approach, with ST and Java and maybe a few other interoperating entities in mind for the design. Similar thinking has to take place with regard to how storage is managed among the different co-operating objects as well. Methinks it would be hard to go very far without wanting this to BE the operating environment in which everything is embedded.
More information about the Squeak-dev