[Vm-dev] Re: Cog and Squeak 4.2

[Eliot Miranda]

On Mon, Sep 20, 2010 at 4:13 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Sun, Sep 19, 2010 at 01:17:33PM -0500, Chris Muller wrote:
> > Hi Eliot and David.  At last week's Squeak Oversight Board meeting, I
> > asked the other board-members whether we should begin considering the
> > 4.2 release of Squeak.  We have accumulated quite a few improvements
> > since 4.1, but the Cog VM would certainly qualify as the crowning
> > cherry atop a fantastic 4.2 release.  The board would like start
> > thinking about organizing around the next Squeak release that would
> > include a designated version of the Cog VM with accessible binaries
> > for all platforms.
> >
> > As part of this act of "organizing," we would like to begin to
> > identify a rough list of tasks and resources.  For example, should we
> > worry about the updates made to the standard VM since Cog branched?
> > Are those still important with Cog?  I'm sure there are other
> > questions which should be asked as well, and we would be grateful for
> > your thoughts on this matter.
> >
> > Cog is a significant common-interest that has energized both the
> > Squeak and Pharo communities.  A "stable" release associated with
> > Squeak 4.2 (and, possibly, Pharo 1.1 or 1.2) would make for a very
> > bright official release, unambiguous accessibility, and a grounded
> > basis from which to move forward.
> >
> > On behalf of the Squeak Oversight Board,
> >   - Chris Muller
>
> Hi Chris,
>
> I think this is an excellent objective for 4.2. There are definitely
> improvements in both the standard VM and Cog branches that should
> be merged, and most of the branched code (C code translation, plugins,
> etc) can and should be combined. It may be a fair amount of work to
> accomplish this, but I do not think that it needs to be completely
> done for 4.2 as long as the direction is set and progress is being
> made in that direction.
>
> In addition to the VMMaker merging, we have branched platform sources
> that will need to be addressed. I'm not sure what will be involved
> here, but my sense is that this is an issue that can be deferred
> until after the 4.2 release cycle.
>
> The most important resource issue is that of building and distributing
> the official releases. For the unix VMs, we have two different build
> systems at the moment. If Ian and Eliot are both agreeable (and we'll
> need to ask), I'd suggest keeping both build systems in place for
> the time being with the standard VM positioned as the "runs on
> anything" version, and Cog as the performance VM that most people
> will use. That said, I'm not sure if there are enough non-Intel
> users left in the world for this to be a concern.
>

Right now Cog comprises two VMs, the Stack interpreter and the JIT.  The
Stack interpreter includes only the context-to-stack mapping and object
allocator improvements to which the JIT adds native code generation and
inline cacheing.  The Stack interpreter is a "run anywhere" VM, and John
McIntosh's use of it on the iPhone shows a 33% speedup relative to the
Interpreter.  Although the Stack interpreter does make slightly more demands
of the run-time than the Interpreter, using a thread or interval timer to
schedule input polling instead of an expensive and erratic counter, and
using alloca to allocate its stack zone, both of these are optional extras.
 The counter can be retrofitted and static memory can be used for the stack
zone.  So one could suggest that on economic and performance grounds we
should ditch Interpreter in favour of the Stack interpreter.  However, the
Stack interpreter, like the JIT can /only/ run closure-enabled images, and
currently eToys hasn't been ported to closures.  So I think for the time
being we have to carry all three VMs.  At least bringing all the VMs into
one VMMaker package will ease the job of keeping them in sync.  [there are 4
forks in my VM life right now, at least 2 too many]

If we do keep all three then I would like us to refactor the source base so
that we can at least share the core interpreter primitives.  In addition I'd
like to refactor to make objectMemory an instance variable.  I've done one
of these refactorings in my internal Teleplace Cog mainline (the hard one of
moving ObjectMemory into an instance variable), and am about to do the other
(the easy one of moving core primitives up to a common superclass above the
interpreters).  The tree then looks like

    ObjectMemory
        NewObjectMemory - faster allocator for the Stack and JIT Cog VMs
          NewCoObjectMemory - support for the JIT

    InterpreterPrimitives - common internal primitives for all three VMs
        Interpreter
        StackInterpreter
            CoInterpreter

This way at least bug fixes and enhancements to the bulk of the primitives
get shared, and there's room to change the object representation which will
bring major performance improvements, at least to the Cog JIT.

But the above may be too much depending on time-lines.  So Chris, what is
the current timeline for the 4.2 release?


Regarding build responsibilities, it's my impression that building
> and distributing the unix VMs has been a long term labor of love
> on Ian's part. It's quite a lot of work, and I think it would be
> a nice touch for the board, on behalf of the Squeak community, to
> mention our continuing appreciation as we move forward on the Cog
> development. And from a selfish point of view, I *really* do not
> want to lose Ian's engagement as long as he is willing to continue
> helping us.
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100922/a46da201/attachment.htm