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!
On Wed, Mar 13, 2013 at 3:45 PM, David Paola <[email protected]> wrote: > Thanks both of you for your answers :-) that self paper is *exactly* what > I am looking for. > > Happy hacking! > > -- > Dave Paola > > On Mar 12, 2013, at 6:47 PM, Robert Krahn <[email protected]> wrote: > > Btw. the most influencing work for Lively's persistency mechanism comes > from Self, see the excellent paper Annotating Objects for Transport to > Other Worlds <http://labs.oracle.com/self/papers/transporter_95.pdf>, > > > On Tue, Mar 12, 2013 at 5:34 PM, Robert Krahn <[email protected]>wrote: > >> Hi, Dave -- >> >> Thanks for the question, this is actually a really fascinating topic :) >> >> First, we wrote up some general information about it (that let's you >> interactively try out things ;) here: >> >> http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Overview.xhtml >> and here: >> >> http://lively-kernel.org/repository/webwerkstatt/documentation/Serialization-Interface.xhtml >> >> I guess the "hairy" part was/is how to deal with "native" objects. JS >> browser >> environments introduce functions and state that are not implemented / >> represented in the JS context but hidden. The DOM and DOM nodes are an >> example >> for that -- you cannot get or modify all the state that would be >> necessary to >> capture or restablish a document / world. >> >> The solution that we came up with and that works very well is to >> implement a >> general JS serializer that walks an object graph starting from root >> objects. >> When certain objects are encountered - e.g. DOM nodes - we make an >> exception >> (this is what the serialization plugins that are mentioned in the worlds >> above >> are for) and store not their full object representation but just "what we >> need >> to know". >> >> The creation of objects from a serialization works accordingly >> create/instantiate objects + run custom init code for the "exceptions". >> >> The shortcomings of this approach are the following: >> - On the application development level you still need to be a bit careful >> what >> objects you reference. Direct pointers to DOM nodes for example won't >> break >> the serialization but when you deserialize you need custom init logic to >> make things work as expected again. >> - The stored representations become big (x-xxx MBs) really quickly. >> Implementing optimizations using the plugin approach is possible but >> requires additional work. >> >> This deals with the "state" of a JS application / Lively world. Another >> point >> that you mention is to capture running computations. From a certain level >> of >> abstraction this is actually the same thing but since JS has incomplete >> metprogramming capabilities (you are not able to reflect on closures, >> e.g.) >> the "hidden state" problem comes up again. For Lively practically this has >> little impact since in the "reactive" browser environment Lively don't >> have to >> implement a "main" function. Anyway, we dealt with the problem and came up >> with a solution. I will describe that in an upcoming post. >> >> Please let me know if you have questions or want a more technical answer. >> >> Best, >> Robert >> >> >> >> On Mon, Mar 11, 2013 at 5:51 PM, David Paola <[email protected]> wrote: >> >>> Hi lively kernel folks, >>> >>> 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. >>> >>> 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? >>> >>> 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. >>> >>> Thanks so much for your energy on lively kernel, I'm looking forward to >>> hearing more and possibly contributing in the future. >>> >>> -dave >>> >>> More info: >>> >>> 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. >>> >>> -- >>> Dave Paola >>> >>> _______________________________________________ >>> lively-kernel mailing list >>> [email protected] >>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel >>> >> >> > > > _______________________________________________ > lively-kernel mailing list > [email protected] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > >
_______________________________________________ lively-kernel mailing list [email protected] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
