Addendum to performance:  If I do my "usual" benchmark which is

Time millisecondsToRun:
   [Interpreter
     translate: 'interp.c'
     doInlining: false]

I get about 85 seconds for the old VM and 86 seconds for the new one.  From 
the tinyBenchmarks methods, I'd have expected a much better performance.  I 
spyOn-ed the code so see where most time is spend:

19.1% {19817ms} Symbol class>>intern:
14.7% {15252ms} StandardFileStream>>next
11.9% {12347ms} CrLfFileStream(StandardFileStream)>>nextPutAll:
7.1% {7367ms} CrLfFileStream(Object)>>retryWithGC:until:

Most time is spend creating symbols.  That's pure smalltalk stuff.  Then a 
large amount of time is spend with file I/O.  Why does this read files?  I 
thought, it's writing C source?  Is it using temporary files?  Whatever, 
this partly explains why faster bytecode interpretation doesn't have such a 
big impact.  And it also shows that for the overall performance it's at 
least as important to have fast I/O.  Last but not least, I wonder about 
retryWithGC:until:.  This is called either via 
ClassBuilder>>fixGlobalReferences (unlikely) or during opening, renaming or 
deleting files.  That that's funny.  I never thought that it would take 
more than 7 seconds to open or delete files...

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf