incremental compilation

[Urs Hoelzle]

> What if the first time a method was called it was compiled by a quick
> and dirty compiler and placed in the compiled method cache ? Then, if
> it turned out not to be used very often it would be kicked out of the
> cache to make room for others. If, on the other hand, it was called a
> lot another, better, compiler would generate an optimized code for the
> method and place it in the cache. This could be exetended to any number
> of levels of optimization, but I doubt that more than two would be useful.

Guess what our ECOOP '91 paper talks about... ;-) The paper describes
a prototype of a recompiling system (the emphasis being on code
quality, not compile speed) and outlines an extension of these ideas
(called "adaptive compilation") which is pretty close to what you
propose.  Right now I'm working on a real implementation.  

We believe that >2 stages do make sense for various reasons, one of
them being that you can generate better code with additional
recompilations.  Our current thinking is to put the first two stages
(a very fast "dumb" compiler and a "fast but reasonable" compiler)
into the VM for bootstrapping.  As a third stage, there would be a
really cool optimizing compiler written in Self.  Besides having the
advantage of using Self for the complicated part, this also gives you
background compilation for free since the compiler is a normal Self
process.

But none of this is running yet, so I won't speculate any further...
I better spend my time implementing it.  The paper will be available
through ftp in July.

-Urs