Actually that paper answered a lot of questions I had about stuff that I want to be able to do in Squeak eventually. I thought I'd read all of the Self papers, but it looks like I missed this one. Thanks for the question, Dave, and thanks for the answer, Robert!<br>
<br><div class="gmail_quote">On Wed, Mar 13, 2013 at 3:45 PM, David Paola <span dir="ltr"><<a href="mailto:dpaola2@gmail.com" target="_blank">dpaola2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Thanks both of you for your answers :-) that self paper is *exactly* what I am looking for.</div><div><br></div><div>Happy hacking!</div><div><br></div><div>
--<div>Dave Paola</div>
</div><div><div class="h5">
<br><div><div>On Mar 12, 2013, at 6:47 PM, Robert Krahn <<a href="mailto:robert.krahn@gmail.com" target="_blank">robert.krahn@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Btw. the most influencing work for Lively's persistency mechanism comes from Self, see the excellent paper <a href="http://labs.oracle.com/self/papers/transporter_95.pdf" target="_blank">Annotating Objects for Transport to Other Worlds</a>,</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 5:34 PM, Robert Krahn <span dir="ltr"><<a href="mailto:robert.krahn@gmail.com" target="_blank">robert.krahn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi, Dave --</div><div><br></div><div>Thanks for the question, this is actually a really fascinating topic :)</div>
<div><br></div><div>First, we wrote up some general information about it (that let's you</div>
<div>interactively try out things ;) here:</div><div><a href="http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Overview.xhtml" target="_blank">http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Overview.xhtml</a></div>
<div>and here:</div><div><a href="http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Interface.xhtml" target="_blank">http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Interface.xhtml</a></div>
<div><br></div><div>I guess the "hairy" part was/is how to deal with "native" objects. JS browser</div><div>environments introduce functions and state that are not implemented /</div><div>represented in the JS context but hidden. The DOM and DOM nodes are an example</div>
<div>for that -- you cannot get or modify all the state that would be necessary to</div><div>capture or restablish a document / world.</div><div><br></div><div>The solution that we came up with and that works very well is to implement a</div>
<div>general JS serializer that walks an object graph starting from root objects.</div><div>When certain objects are encountered - e.g. DOM nodes - we make an exception</div><div>(this is what the serialization plugins that are mentioned in the worlds above</div>
<div>are for) and store not their full object representation but just "what we need</div><div>to know".</div><div><br></div><div>The creation of objects from a serialization works accordingly</div><div>create/instantiate objects + run custom init code for the "exceptions".</div>
<div><br></div><div>The shortcomings of this approach are the following:</div><div>- On the application development level you still need to be a bit careful what</div><div> objects you reference. Direct pointers to DOM nodes for example won't break</div>
<div> the serialization but when you deserialize you need custom init logic to</div><div> make things work as expected again.</div><div>- The stored representations become big (x-xxx MBs) really quickly.</div><div> Implementing optimizations using the plugin approach is possible but</div>
<div> requires additional work.</div><div><br></div><div>This deals with the "state" of a JS application / Lively world. Another point</div><div>that you mention is to capture running computations. From a certain level of</div>
<div>abstraction this is actually the same thing but since JS has incomplete</div><div>metprogramming capabilities (you are not able to reflect on closures, e.g.)</div><div>the "hidden state" problem comes up again. For Lively practically this has</div>
<div>little impact since in the "reactive" browser environment Lively don't have to</div><div>implement a "main" function. Anyway, we dealt with the problem and came up</div><div>with a solution. I will describe that in an upcoming post.</div>
<div><br></div><div>Please let me know if you have questions or want a more technical answer.</div><div><br></div><div>Best,</div><div>Robert</div><div><br></div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Mon, Mar 11, 2013 at 5:51 PM, David Paola <span dir="ltr"><<a href="mailto:dpaola2@gmail.com" target="_blank">dpaola2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi lively kernel folks,<br>
<br>
I've spent the past month or so digging around in several language VMs -- CPython, Rubinius, Topaz, Pypy, etc in an attempt to add the equivalent of the original Smalltalk "snapshot" VM primitive. Obviously I have been naive.<br>
<br>
I've learned a lot, above all else that I'm not giving up. I have a decent, academic understanding of compilers, interpreters, VMs (and a foggy understanding of JITs), and was curious if anyone could clarify how the lively kernel serializes the world into JSON. Was this hairy? What were the hardest parts?<br>
<br>
I realize everyone has a full time job and can't hand-hold a newbie, so any direction at all would be appreciated. I tried to pick apart the Squeak source code but without a background in the Squeak architecture, it was fruitless.<br>
<br>
Thanks so much for your energy on lively kernel, I'm looking forward to hearing more and possibly contributing in the future.<br>
<br>
-dave<br>
<br>
More info:<br>
<br>
I realize that the "high level" idea of snapshotting a running VM basically involves serializing the object memory, bytecode, and instruction pointer, and then deserializing that on "resume". Most of the issues I'm encountering lead me to believe I have an incomplete understanding.<br>
<br>
--<br>
Dave Paola<br>
<br>
_______________________________________________<br>
lively-kernel mailing list<br>
<a href="mailto:lively-kernel@hpi.uni-potsdam.de" target="_blank">lively-kernel@hpi.uni-potsdam.de</a><br>
<a href="http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel" target="_blank">http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
lively-kernel mailing list<br>
<a href="mailto:lively-kernel@hpi.uni-potsdam.de">lively-kernel@hpi.uni-potsdam.de</a><br>
<a href="http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel" target="_blank">http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel</a><br>
<br></blockquote></div><br>