Smalltalk › Squeak › Squeak VM

Re: Cog and Squeak 4.2

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Eliot Miranda-2

Re: Cog and Squeak 4.2

On Mon, Sep 20, 2010 at 4:13 AM, David T. Lewis <[hidden email]> 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