On 4-Jul-08, at 7:35 PM, Eliot Miranda wrote:

> But that's exactly what this project would allow one to do.  One  
> implements a VM in Smalltalk as cleanly designed as one can.  If  
> implementing a JIT then include a simulator for the processor.  Then  
> simulate this written-in-Smalltalk VM and translate this clean  
> design to (e.g.) C removing polymorphism and generating vanilla code  
> based on the type information collected.

I think collecting type information via the simulation is both  
overkill and insufficient. On one hand, the VM code is immutable while  
it runs, unlike Smalltalk code. Gathering type feedback at runtime is  
a great technique because it can respond to changing code, changing  
usage or the need for reflection. But the VM doesn't need any of that  
- it just needs a static snapshot of the possible types that could be  
encountered at each call site.

On the other hand, simulation may not be able to provide that. It runs  
the risk of not exercising all the code paths and therefor generating  
incomplete type information. Even with a complete test case to run in  
the simulator, there's quite a bit of indeterminism in the system.  
When interrupts happen, when garbage is collected, where objects  
happen to be allocated, all that can affect the code flow in the system.

I think a static type inferencer would be a better bet. There are  
several out there, and it probably wouldn't be tricky to press them  
into service. Chuck, for example, adds a "specific implementors"  
command to the browser that fits the bill perfectly. The VM isn't  
likely to be hugely polymorphic in any case, so it probably wouldn't  
be difficult to track down oddities that the inferencer turns up.

Colin