Hi, Dan-

Yes, the scheme you mention for Snort (I like it) sounds about like what we considered for recursive compilation, and so does way of
preventing nontermination.  I don't see any reason that in principle it wouldn't work.

The big issue is the speed, which you aptly captured with the word "lumbered".  There are two speed issues:

- Startup time: Strongtalk already doesn't start as quickly as Squeak because of the initial compilation "bulge".  Snort would start
even more slowly, not only because the compiler is being interpreted, but also because it is being compiled.  This might not be to
bad a problem, or it might.  The critical issue is what the performance locality profile of the compiler is.  In other words, does
the compiler spend most of its time in some small fraction of its code, or does most of the compiler get exercised pretty heavily.
I don't have an answer for that, but the more locality it has, the faster it would speed up.

- Asymptotic compiler speed: once the compiler is running essentially full speed, is that fast enough?  Even with all the Strongtalk
optimizations in place, such code is still a lot slower than fully optimized C++ (in principle it could get fairly close to C++
performance, but the limiting factors are the fact that the best algorithms for more advanced optimizations like scheduling and
register allocation are usually too slow to run in realtime, as well as being a giant pain to write efficiently).  So I would expect
that a compiler similar to the Strongtalk one written in Smalltalk would run about 5-10 times slower than the Strongtalk compiler
(although with tuning you might eventually be able to speed it up a lot).

If you have to recompile all the perf. critical code everytime the system starts up, all this might mean very slow startup, and
noticeable pauses for compilations thereafter.  But one way to get around all of this might be to keep the compiled code in
ObjectMemory and save it with the image, in which case you could start the system in an already optimized state (complicates image
portability, but worth it).  In this case, people would generally want to do 'training' runs of their code to get them mostly
optimized, and then save the image.  Compilation then becomes a fairly rare thing after training is done.

Then, if compilation becomes a rare thing, you could even have different compiler modes for fast vs. good compilation, and then run
really good optimizations to get closer to C perf. during the training runs, and use a faster compiler (perhaps even really simple,
fast non-inlining one) during normal execution, if the really good one is too slow.  This would let your good compiler eventually do
better optimizations than we could afford, with the sky the limit!

-Dave