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 side-by-side.
comment? ideas?
david
At 10:59 AM 2/26/99 -0500, you wrote:
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?
Thanks! Mark
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
-- j. david farber oo architect+mentor numenor labs incorporated in sunny boulder colorado dfarber@numenor.com www.numenor.com
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 side-by-side.
comment? ideas?
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.
- Dan
At 01:35 PM 2/27/99 -0700, you wrote:
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 side-by-side.
comment? ideas?
This had been done by IBM Hursley lab. At one point, the IBM folks from Hursley has mentioned about an 'official' release of UVM (universal virtual machine) that will be able to execute both Java and Smalltalk bytecode set to some of its larger customers in Smalltalk Solution conference. Subsequently, the release of VisualAge Java V1.0 did just that (at least the beta version if I remember correctly), although it wasn't mention in anywhere that the VM is capable of interpreting both bytecode sets. You can actually write a Smalltalk method in VA Java IDE, save it (i.e. compile it correctly), and execute it. The performance in VA Java 1.0 was terrible, however, I don't know how much the bloated VM contributed to the overall sluggishness of the product. I have not tried this in V2.0.
-- Mark Wai Wator InnoVision
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
David Farber -
Mark Wai