stéphane ducasse writes:
 > 
 > > However there are a few options that I've thought about.
 > >
 > > One is to recompile the method with a larger PIC. The plan is for
 > > Exupery to be driven by dynamic feedback to automatically
 > > compile the hotspots. This is one reason why I've used a slow
 > > algorithm for register allocation that generates good code.
 > 
 > So if I'm correct in all this strategy the game is to see if the 
 > feedback
 > and the recompilation is worth the extra tests needed at run-time when
 > the method is "normally" executed.

Exupery's strategy is to focus on compiling only the
hotspots. Compiled code will always take more time to produce (1) and
take more space than bytecodes. We also already have a decent
interpreter to execute non-speed critical code.

There is always a compromise between compiling for execution speed or
compilation speed. Exupery assumes that the interpreter will act as
the fast compiler. Exupery doesn't yet have a serious optimiser, but
the compromises necessary are the same that I needed to make to write
the compiler in Smalltalk. So while, we're not yet getting the run
time speed benefits, it is faster to develop this way.

Bryce

(1) I've read a paper that suggested that a really quick compiler
could compile as fast as an interpreter could execute the code. I
think the paper was from '86.