[Vm-dev] About StackInterpreter VM

[Eliot Miranda]

On Thu, Jan 6, 2011 at 5:47 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> Hello, VM hackers
>
> i just want to ask, how well StackVM could replace original Squeak VM?
> If that's only image format aspect, then i think we can deal with that
> and forget about it once and for all.
> Also, i suspect that stack-interpreter VMs will be much more stable
> (because not including JIT), so people can always
> use it as a fallback solution if they can't make own code running stable on
> Cog.
>
> But if there are more issues than just image format, then please let me
> know.
> Because maintaining two different VMs is too much, especially that we
> don't have enough human resources for that.
> And so, we must choose. And choice is obvious, as to me.  :)
>

The main issue is that it relies on a heartbeat.  It doesn't have to rely on
a heartbeat, but it's performance suffers.  I should measure but I would
guess overall performance would drop by 3% - 5%.  But also the use of an
interrupt counter (as in the standard VM) is a very bad thing since its
frequency depends on what the VM is doing.  If the VM is doing lots of slow
primitives (large integer arithmetic) it counts very slowly and the VM's
interrupt latency soars.  If the VM is not doing lots of sow primitives it
burns cycles polling for I/O too frequently (or on fetching the time to
prevent it from polling for I/O too frequently).  So IMO heartbeats are a
really good idea.  However, the heartbeat isn't well-supported on every
platform.  In particular we have been fighting linux at Teleplace for some
time and so far we don't have a bullet-proof heartbeat.  It works perfectly
well on Mac OS X and Windows.  I also wonder if there are minimal embedded
systems that don't provide one of the two alternatives for heartbeats, a) a
high-priority thread that blocks on a timeout and b) a periodic interrupt
timer.

>
>
> P.S. Can you please remind me, what conversion is needed between old
> image format and one which is edible by stack-based VM?
> And why just don't add it by default, so Stack VMs (and Cog) can read
> old image format (closure one)?
>

The StackVM requires closures, which we have.  Also, nut not necessarily,
the stack VM uses native float ordering.  Of course the right fix here is to
make the standard VM support native float ordering.  It makes no sense for
the standard V to waste cycles reversing floats on every floating-point op.
 Whether I should have exposed that in the image format and image segment
format is debateable; it could have been hidden at snapshot or image format
write time.  Btu that the standard VM doesn't hold floats in platform order
at run-time is IMNAAHO absurd.

best
Eliot

>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110106/2f4d84ec/attachment.htm