[Vm-dev] CogVMExecution Flow

[Eliot Miranda]

Hi Chris,

On Tue, Jun 14, 2016 at 6:23 AM, Chris Cunnington <brasspen at gmail.com>
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...  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