[squeak-dev] Anyone know the following about Slang?

Eliot Miranda eliot.miranda at gmail.com
Sat Jul 5 05:59:16 UTC 2008


On Fri, Jul 4, 2008 at 9:57 PM, Colin Putney <cputney at wiresong.ca> wrote:

>
> 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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080704/164b8934/attachment.htm


More information about the Squeak-dev mailing list