Subj : Re: SpiderMonkey's serialization/deserialization
To   : anton muhin
From : Brendan Eich
Date : Wed Sep 15 2004 02:44 pm

anton muhin wrote:
> Hello, Brendan!
> 
> First of all, thank you very much.


You're welcome.


> I manage to compile and restore scripts with you help. And if you don't 
> mind I have a couple of questions:
> 
> 1. Compiled script is approx. 2 times bigger than the source, was it 
> intentional (e.g. developers tried to speed things as mush as possible)? 
>  If one studies compiled scripts it's easy to find out that no string 
> merging is performed that obviously leads to bigger size.


You are referring to the XDR'd script string size?  Yes, we favored time 
over space.  String interning in each XDR'd stream could save a bunch of 
space, depending on the script.  See 
http://bugzilla.mozilla.org/show_bug.cgi?id=104170 for a bug about this 
problem as it affects the XUL FastLoad File used by Mozilla XUL apps to 
speed up Ts (startup time).


> 2. There seems to be no public API function that fetches JSScript from 
> the JSObject.


JS_GetPrivate.


> (now I just use 
> JS_GetPrivate, but it, obviously, breaks incapsulation).


Not really -- I see no point in hiding the fact that the script object's 
private data is the JSScript.  The precedent here was JSFunction, which 
is a function object's private data type.  That precedent goes back to 
the birth of the engine.


> 3. And the last question. If I understand correctly, you was the person 
> that wrote most of SpiderMonkey. If it's not a secret, how much time it 
> took?


It depends on what you mean by "SpiderMonkey" and at this point, lots of 
the code has been tended by others, or was written originally by others 
(some obviously so: the David M. Gay jsdtoa.c code, based on a 
well-known paper that Gay and Guy Steele wrote).  Any names I mention 
below are just ones that pop to mind; I'm not listing all contributors, 
or most valuable contributor (shaver, I love you man! ;-).  Some day, a 
book might be written about the whole Mozilla history -- not now.

I wrote the "Mocha" runtime in about a week in May, 1995, for inclusion 
in Netscape 2.  The heat was on to do this well enough (ulp) and quickly 
enough to then build a DOM (so-called "Level 0", now) that used this 
engine, grafting the DOM code onto the side of Eric Bina's HTML layout 
code.  Mocha used ref-counting and a discriminated union instead of a 
tagged jsval type, but otherwise was similar in gross architecture to 
SpiderMonkey (stack machine, byte-coding, decompilation for toString on 
a function object, shared getProperty and setProperty hooks per "class", 
etc.).

In 1996, just before we started working with ECMA to standardize JS, I 
rewrote Mocha as SpiderMonkey, switching to tagged jsvals and GC.  In 
1997, I added regular expressions based on Perl 4(!).  That all led into 
ECMA-262 Edition 3.  I stopped working on the code officially in 1998, 
when I helped co-found mozilla.org.

In those early years, a lot of the time I spent was not spent on the 
engine. Writing it was fast, repenting was leisurely.  But mainly, I was 
very busy implementing "DOM Level 0", helping with LiveConnect, and 
(finally, by 1997) leading a team of 8 or more JS hackers at Netscape.

Multi-threading work was initially done (and very well) by Jawahar (I'm 
sorry I forget his last name), with my advice and review, for Netscape's 
multi-threaded server JS embedding, in 1996 or so. In 1998, Bjorn 
Carlsen added "Bacon-bit" style compare-and-swap optimization to speed 
up uncontested lock acquisition.  Years later, I worked hard to make the 
remaining lock overhead (which could make a benchmark 3x slower when run 
in a JS_THREADSAFE-compiled engine, compared to in the single-threaded 
engine) just about disappear for most profiles (see 
http://bugzilla.mozilla.org/show_bug.cgi?id=54743).

Roger Lawrence rewrote the regexp code twice, to implement the 
Perl-5-ish ECMA-262 Edition 3 features, and most recently to restore the 
higher-performance bytecoded NFA architecture used originally (and used 
in Perl).

A big patch I did since Mozilla started: 
http://bugzilla.mozilla.org/show_bug.cgi?id=56940 "O(n**2) and O(n**3) 
growth too easy with JS string concat".  Strings are still bloaty 
without a better GC, but this is about as good as they'll get with the 
current architecture.

A fun bug that shows you've invented a language being used way beyond 
its original design limits: 
http://bugzilla.mozilla.org/show_bug.cgi?id=80981 'Need extended jump 
bytecode to avoid "script too large" errors, etc.'.  I call that a 
victory condition.

/be

.