Subj : Re: SpiderMonkey's serialization/deserialization
To   : anton muhin
From : Brendan Eich
Date : Tue Sep 14 2004 07:01 pm

anton muhin wrote:

> I'm going to achieve the goal in the following way: after I compile the 
> script I want to save global object of the appropriate context. The 
> first question is if this is right way to move?


You can use XDR -- Mozilla apps do, for XUL FastLoad.  Remember that the 
scripts you precompile and serialize need to be executed, so the vars 
and functions they declare will be recreated on each execute against a 
distinct global object.  The point of XDR is *not* to try to save the 
results of declaration bytecodes committed to global objects, and 
restore them from an XDR stream.

Rather, you restore (deserialize) scripts, and run them as usual.


> The second question: if I store the global object, are the references to 
> native objects' methods (both standard ones and implemented by me) 
> stored correctly?


No.


> I suppose the answer is yes due to highly dynamic 
> nature of JavaScript, but just in case.


Good question.  The reason is that serializing a bunch of native methods 
and private data is hard and bug-prone.  Instead, based on profiling, we 
reckoned that for apps such as Mozilla, the main savings is in avoiding 
recompiling scripts.  Running their prologs to process declarations of 
vars and functions is not very costly, so that processing should be done 
after deserialization using each particular global object (distinct 
global chrome window in Mozilla, e.g.).

This is why you see only some native classes supporting the xdrObject hook.

/be

.