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 at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Tim Rowledge
> Sent: Thursday, July 18, 2002 1:52 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Animorphic ST (Strongtalk) released!
> 
> 
> Dan Ingalls <Dan at 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 at sumeru.stanford.edu, 
> http://sumeru.stanford.edu/tim Any given > program will expand 
> to fill available memory.
> 
> 
>