[Vm-dev] Merging SqueakVM and CogVM

[Eliot Miranda]

Hi All,

On Wed, Jul 7, 2010 at 3:11 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Wed, Jul 07, 2010 at 11:22:33PM +0200, Levente Uzonyi wrote:
> >
> > I was wondering about how this will be done. Will it be done? If so, is
> > there a plan for it? I saw that Eliot added Juan's BitBlt fixes to Cog,
> > but that's only one of the many enhancements of the SqueakVM "branch".
>
> That's a very good question, thanks for opening the discussion.
>
> Personally, I do not have a good sense of how this should be handled.
> I expect that we will want to keep the traditional SqueakVM alive
> and healthy for at least a few years into the future, but I do not
> know if it is better to merge it with the StackVM, or just let it
> be separatedly maintained for some period of time.
>
> Does anyone have some perspective or recommendations on how this
> might best be handled?
>

One issue is whether to have three VMs or two.  Notionally the
StackInterpreter could replace the base interpreter because it is portable C
with no JIT component.  However its event handling model requires at least a
periodic timer and preferrably a separate heartbeat thread.  If we can
assume all platforms will provide at least an interval timer (e.g.
equivalent to unix's setitimer) then I see no need for Interpreter.

Another issue is that the current class hierarchy is poor; it couples the
execution engine to the object representation, making it very difficult to
change the object representation.  I have already changed this in Teleplace
and some time we'll release this (again forgive me for not being able to
give dates or firm commitments but you can be pretty confident it'll
happen).  The new class structure looks like the following where S stands
for Separate, as in separate from ObjectMemory.

    ObjectMemory
        NewObjectMemory             - performance improvements and support
for non-GC allocations for stack-to-context mapping
            NewCoObjectMemoryS   - extensions for the JIT (method header can
point to JIT method.  JIT needs a store check)

    StackInterpreterS                       - accesses a NewObjectMemory
through an objectMemory inst var
        StackInterpreterSPrimitives    - primitives grouped for clarity
            CoInterpreterS                   - modifies StackInterpreter to
mate with the JIT (two frame formats, etc, etc, etc)
                CoInterpreterSPrimitives - overridden primitives grouped for
clarity
                    CoInterpreterMTS       - a subclass that implements a
multi-threaded VM analogous to Python's Global Interpreter Lock
                                                       but far more
efficient

Right now our threaded VM is working with a hack to stop objects moving
while a threaded call is in progress.  First tenure any young arguments via
a tenuring incremental GC, then lock out full GCs until the call is
complete.  So old objects won't move whole calls are in progress which won't
work as soon as one always has a threaded call in progress.  Further, the
current object representation is over-complex and slow and doesn't exploit
64-bits as well as it might.  So I'm starting work on a better object
representation and a pinning garbage collector where specific objects
(including arguments to threaded calls) can be kept stationary.



So I would like to see the following:

1. the Interpreter be allowed to die and the StackInterpreter take its
place.

2. some time soon the current class structure be discarded in favour of the
above or something like it (for example having Primitives at the top is
probably a better structure; there are space and complexity advantages to
creating a minimal CoInterpreter that doesn't have localIP localSP or
localFP or the at cache, and so it could inherit from a root Primitives
class and avoid StackInterpreter baggage necessary to make a fast
interpreter but irrelevant to a JIT).

3. efforts in the dialects at creating a small base image and loadable
packages so that when a faster object representation is available we can
more easily convert the core image to the new object representation and
build up the full image.

4. a 64-bit image format developed from the new object representation with
immediate double support that will obsolete the existing 64-bit image by
virtue of having much better performance (especially for Float).


Point 1 needs careful discussion.  I note that John McIntosh has started
porting the StackInterpreter to iPhone which is a necessary first step in
seeing whether the StackInterpreter is a suitable replacement for
Interpreter.


There are a couple of minor things that need to get done soon.  One is to
support objects-as-methods in the Cog JIT.  Another is to support JIT-ing
long-running interpreted methods by checking backward branches.  Any brave
soul who wants to learn Cog could have a go at these.


cheers,
Eliot


> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100708/ddb7fdaa/attachment.htm