Hi Igor,<br><br><div class="gmail_quote">On Mon, Aug 16, 2010 at 9:42 AM, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hello,<br>
<br>
i want to adopt an image-side scheduling for Cog and since<br>
everything which sounds like &#39;Process&#39; will be wiped out from VM,<br>
i need a way to cleanly switch the active context to a new one.<br>
<br>
I think that as a guide for implementation could be taken<br>
CoInterpreter&gt;&gt;transferTo: newProc from: sourceCode<br>
<br>
but i am a bit confused by following:<br>
<br>
self push: instructionPointer.<br>
...(switching code)...<br>
instructionPointer := self popStack.<br>
<br>
<br>
does that means, that instruction pointer is always stored in last<br>
stack position<br>
instead of some fixed slot of context?<br></blockquote><div><br></div><div>You need to internalize <a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/">http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/</a>. 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&#39;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&gt;&gt;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&#39;s iframeSavedIP slot which holds the bytecode pc (at which the interpreter should start executing).</div>
<div><br></div><div><br></div><div>(*) of course Cog does use contexts, but they are used as little as possible.  When you say &quot;thisCOntext&quot; 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.</div>
<div><br></div><div>HTH,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</font></blockquote></div><br>