<br><br><div class="gmail_quote">On Fri, Jul 4, 2008 at 9:57 PM, Colin Putney <<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
On 4-Jul-08, at 7:35 PM, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
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.</blockquote>
<div><br>Yes, good point. The VM is a closed world so the inferencer should be able to do a good job. Hints from the programmer on how to resolve perform: could close any loopholes. A much better approach.</div></div>