<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 6:23 AM, Chris Cunnington <span dir="ltr"><<a href="mailto:brasspen@gmail.com" target="_blank">brasspen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<pre style="color:rgb(0,0,0);font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px"> 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).</pre>
</blockquote>
<br>
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?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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.<br></div></blockquote><div> </div><div>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.</div><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">That's fine, because you have the original CompiledMethod untouched
with its bytecodes. </div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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? <br></div></blockquote><div><br></div><div>OK, you should read <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> 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.</div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Chris</div></blockquote></div><br clear="all"><div>HTH</div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>