[Vm-dev] CogVMExecution Flow

Chris Cunnington brasspen at gmail.com
Wed Jun 15 11:35:49 UTC 2016


> ------------------------------------------------------------------------
> Hi Chris,
>
> On Tue, Jun 14, 2016 at 6:23 AM, Chris Cunnington <brasspen at gmail.com 
> <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>>
> wrote:
>
> >//>//>/a2) "marries" the context in the image that invoked the snapshot />/primitive (a stack frame in the stack zone is built for the context, and />/the context is changed to become a proxy for that stack frame). />//>//>/When saving to disk, does the stack state of a married frame inside a />/CogStackPage bitmap get saved back to the stack of a MethodContext 
> instance? />//
> Yes.  And this happens also whenever a stack page must be evacuated to make
> room for new frames; the state of the frames on that poage are written back
> to contexts on the heap.
>
>
> >//>/The CompiledMethod of a MethodContext is not changed in an image. It is />/compiled by the StackToRegisterMappingCogit and stored in a frame in the />/CogStackPage as a copy. This is not saved when the image is saved to 
> disk. />/The machine code is thrown away. It only existed in RAM. />//
> But it /is/ changed.  The slot holding the method header pointer is
> replaced y a pointer to the cogged method.  So again when a snapshot is
> made, the machine code is thrown away and all the compiled methods with
> machine code are converted back to their normal form.
>
> So in an image file there's no remnant of the fact that it was saved on the
> Cog VM and it can start up just as well on any other kind of VM using the
> same object representation (except that we only have Interpreter VMs for
> the V3 object representation).
>
> That's fine, because you have the original CompiledMethod untouched with
> >/its bytecodes. />//
> Untouched except for its header which has been copied to a slot in the
> start of the cogged method, the header having been overwritten by a pointer
> to the cogged method.
>
>
> >/But if in the process of execution the state of a stack under a />/MethodContext changes, and it will, and the entire content of the />/CogStackPages bitmaps will be nulled out and not saved to disk in the 
> image />/as new, extra memory, then does the married frame shiv its content back />/into every MethodContext instance on snapshot and quit? />//
> I don't understand.  Stack pages hold some number of activations,
> approximately 40 per page, and there are typically 80 pages.  When a fresh
> page is needed, all the frame state on the oldest page get written to the
> heap as a chain of contexts.  When a snapshot is made, all the pages get
> written to the heap as contexts, leaving an empty stack zone.  So the image
> file contains vanilla context objects that retain no vestige of them having
> once existed on a stack page.  So again the image file can be resumed on
> any suitable VM.
>
>
> >/The frame has a header that can point to the CompiledMethod with 
> bytecodes />/or to a machine code compiled version next door in the CogStackPage 
> bitmap. />/But if you copy the stack of a MethodContext into its married frame, 
> then />/the stack in the MethodContext is out of date, while the CoInterpreter />/spins everything it needs in the separate world in CogStackPages; then, />/when you save to disk, are you, as a last effort, saving state back from />/every married frame to its original MethodContext instance? />//
> OK, you should read
> http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/
> fir the details but...

Thanks you for looking at these questions.

These answers make me better able to read the post again and get a 
stronger grip on Context/Frame marriages.

Chris

>   No, there's no out-of-date problem.  First, a
> context that is married has its sender inst var replaced by a pointer to
> the frame.  You can't see this; the VM hides it from you, but /all/
> accesses to context objects first check the sender field.  If the sender
> field is a pointer to a frame then the VM computers the state being
> accessed from the context (its sender, pc,  stack pointer, stack contents)
> from the frame.  To avoid the out-of-date problem, when the context is
> married the receiver and arguments of the method are copied into the
> context, and these are are read-only.  If a widowed context is accessed,
> then the sender and pc are nil, the stack pointer is the same as the
> argument count, method, receiver and arguments are unchanged, so there is
> no out-of-date problem.
>
> Where the "out-of-date" problem /usually/ rears its ugly head in Smalltalk
> VMs is when a block wants to access the outer temporaries of its home
> context.  If the home context could be either a proxy for a frame or a
> context object, and so to keep the context object's temporaries up-to-date
> we would have to copy the state of the frame to the context whenever a farm
> was returned to, which causes slow clunky returns that require complex
> tricks to optimise.  Except that our closure design /doesn't/ access the
> outer temporaries of the home context.  Instead any temporaries that a
> block and a home context share that each might write to after the block is
> created are kept in an Array on the heap (a temp var indirection vector)
> and other values of temps that aren't written to after a block is created
> are copied into the block, so block activations are completely independent
> of their home context (and any other block in the method).  That's the
> while point of the closure design.  It is why temporaries are represented
> as they are; it soles the out-of-date problem by making it impossible to
> /have/ an out-of-date problem.
>
>
> >/Chris />//
> HTH
> _,,,^..^,,,_
> best, Eliot
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/264dc7a9/attachment-0001.htm
> ------------------------------------------------------------------------
>
>   * Previous message:[Vm-dev] CogVMExecution Flow
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/022221.html>
>   * Next message:[Vm-dev] comp=
>     ioFindExternalFunctionIn("j_interpret", handle);
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/022231.html>
>   * *Messages sorted by:*[ date ]
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/date.html#22230>[
>     thread ]
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/thread.html#22230>[
>     subject ]
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/subject.html#22230>[
>     author ]
>     <http://lists.squeakfoundation.org/pipermail/vm-dev/2016-June/author.html#22230>
>
> ------------------------------------------------------------------------
> More information about the Vm-dev mailing list 
> <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/4283ee7b/attachment.htm


More information about the Vm-dev mailing list