[Vm-dev] Merging SqueakVM and CogVM

[Igor Stasenko]

+1 for separating an ObjectMemory and Interpreter entities.
And we are discussed this before. Moreover, ideally, i think we should
go further and
split on even smaller parts, based on their roles inside VM.

This in fact will get us closer to a pure smalltalk-based VM
implementation , which is easy
to examine and modify
(with some rules, that it should be easily translatable to low-level,
early bound language , such as C).

On 8 July 2010 19:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> 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
>>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.