Being curios about how this stuff works, and not knowing anything about how JIT VMs work, I have a couple of questions.
First, are you you talking about adding JIT to Squeak? Or something more? What does Jitter do? How does it relate to this discussion?
When you say compile a method, I take that to mean take a normal Smalltalk bytecoded method and compile it into native machine code. What does the compiled method look like? Is it just a sequencing of the machine code that the interpreter would normally run as it processes each bytecode? It must be more than that right? Because a bytecode-threaded interpreter would get to the end or processing one bytecode, then pull the next bytecode and jump directly to the start of the next bytecode's machine code (not even needing to do anything like a case statement). Thus, I wouldn't think that a simple sequencing of the machine code for each bytecode would buy you much (and it would take up a good bit of space too). There must be some more optimization going on in the compilation of bytecodes into machine code right? If that's the case, could someone elaborate on that?
Also, once a method is compiled to machine code, why would there be any need to keep the bytecodes around (as Tim descibes)? Can't you just throw away the old bytecodes at that point? Ah...but perhaps it's so that the image can remain portable to different architectures...is that it?
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Thursday, July 18, 2002 1:52 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Animorphic ST (Strongtalk) released!
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
So, what happens when you start it?
It starts to run the first method which is not translated so it runs the interpreter Things lumber along for a while this way until something notices the umpteenth execution of the same method and asks for it to be compiled Now the compiler starts to run but, of course, it's not translated so it starts kind of slow Along the way the compiler hits some inner loops and these need in turn to be translated Gradually the compiler speeds up until it runs as fast as StrongTalk, and what more could we ask for?
This is, of course recursive but, as long as the system
supports both
interpreted and translated code, I don't think it's a
problem as long
as you recognize three states of a method:
Interpreted Being translated Translated
Some time ago I suggested a similar possible approach to allow writing of the translator in Smalltalk so that it would be more intelligable, manipulable etc. It's not a particularly original idea of mine, being loosely based on my (probably poor) understanding of Ian P's doctoral thesis and vague discussions before then with LPD, Schiffman, Baker, Eliot M, etc.
The good news is that surprisingly little would need to change in the VM code we already have. An extra oop in compiled methods (or maybe in a lookup cache, who knows) to point to the translated chunk if it exists, some way to queue up an untranslated method for processing, a way to set the translated oop once the translation has finished. The current interpreter would merrily keep going and the translator would run as a suitable priority process. Recognising the middle state of 'in translation' would be a small optimisation to allow for dumping the translation of a method that had been changed since it was queued up.
I think you could even fake up the support framework by making the system allow for the 'translated' methods to be just the normal bytecodes, thus saving having to write the actual translator till later. It would provide nice confirmation of the functionality being reasonable quite quickly.
It would possibly be reasonable to allow the image to be saved with translated methods intact so long as a check were plausible to drop them if the image started on a different machine.
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Any given > program will expand to fill available memory.