On 16 August 2010 21:26, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Igor,
On Mon, Aug 16, 2010 at 9:42 AM, Igor Stasenko siguctua@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 http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-.... 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).
I am actually need few things to understand: how much state should be preserved/swapped and in what order. I seen you post and even tried to read it befor, but reading it without using in practice is almost waste of time, because i best work using trial & fail process, instead of reading books and following rules :) That's how my mindset works, and that's why i liked smalltalk so much, when i first seen it, because it makes trial & fail process extremely easy and enjoyful. But thanks for reminder, i'll use your blog post as a reference :)
(*) 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.
Yes, i am aware that contexts is used as less as possible. But from language perspective, a context is still a smallest possible unit of computation, which you can safely operate with. So, it is logical to have a primitive which switching an active context, instead of active process(es). Also, same thing is userful for callbacks, by taking a simple block closure, which should handle callback and turning it into context, which then can be activated, once callback is called.
HTH, Eliot
-- Best regards, Igor Stasenko AKA sig.