[Vm-dev] Switching an active context in Cog

Eliot Miranda eliot.miranda at gmail.com
Mon Aug 16 18:26:45 UTC 2010

Hi Igor,

On Mon, Aug 16, 2010 at 9:42 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> Hello,
> i want to adopt an image-side scheduling for Cog and since
> everything which sounds like 'Process' will be wiped out from VM,
> i need a way to cleanly switch the active context to a new one.
> I think that as a guide for implementation could be taken
> CoInterpreter>>transferTo: newProc from: sourceCode
> but i am a bit confused by following:
> self push: instructionPointer.
> ...(switching code)...
> instructionPointer := self popStack.
> does that means, that instruction pointer is always stored in last
> stack position
> instead of some fixed slot of context?

You need to internalize
Cog /does not/ use contexts for managing execution.  It uses stack frames,
and in an inactive stack frame on top of stack the instructionPointer is at
top of stack (*).  So I suggest you read the above blog entry at least three
times until it all starts to make sense.  Then you'll have to understand how
the CoInterpreter complicates things by having two kinds of frame, one for
interpreted methods and one for JIT-ed native methods, see CoInterpreter
class>>initializeFrameIndices, and understand that an interpreter frame
needs two instruction pointers, the normal one which is a return address for
native code that jumps into the interpreter (see ceReturnToInterpreter:),
and the one in the interpreted frame's iframeSavedIP slot which holds the
bytecode pc (at which the interpreter should start executing).

(*) of course Cog does use contexts, but they are used as little as
possible.  When you say "thisCOntext" a context gets created for a frame,
and when teh stack zone fills up, stack pages are freed by copying all
frames on a page to the heap as contexts, and when a snapshot is created all
stack pages are freed, converting all frames to contexts.  So from the image
this optimization is completely invisible, apparently all method activations
are contexts, but the VM creates context objects only when necessary or
convenient, and certainly /not/ on every send.


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

More information about the Vm-dev mailing list