107907 - chrome JS should use "delayed FastLoad" for its functions

Status: RESOLVED DUPLICATE of bug 678037

(Core :: JavaScript Engine, enhancement)

Description

[Brendan Eich [:brendan]]

From bug 67618:

JS profiler says that starting up through profile manager to first browser
window (it loads the default mozilla milestone home page) compiles 376 uncalled
JS functions consuming at least 108192 bytes of net-request-total heap space,
while 80 compiled functions are called at least once and take at least 20350 bytes.

The fix entails changes to the JS engine (first patch coming up) and to the XUL
prototype script handling code (second patch, later -- probably tomorrow).

/be

Comment 1

[Brendan Eich [:brendan]]

Noting bug 104170's dependency on this bug, because to share FastLoad strings
originating from JS, we'll need the hooks in the forthcoming patch.

/be

Comment 2

[Brendan Eich [:brendan]]

Attachment: js/src patch to support custom script-literal value serialization

Comment 3

[Brendan Eich [:brendan]]

Close but no cigar -- this is work in progress, I'll finish it after 0.9.6 rush
hour traffic clears.

/be

Comment 4

[Brendan Eich [:brendan]]

Attachment: updated patch to js/src, ready for review

This patch adds two layers of laziness:

1.  If you configure rt->valueTranscoder, it will be used instead of
JS_XDRValue when xdr'ing atoms mapped by a script.  If this callback, when
decoding a value, returns true via *lazy, the mapped atom will be null.  If the
script doesn't use that literal, no cost and pure gain.  If the script uses
that literal, then the rt->lazyValueDecoder callback will be invoked when a
thread tries to get that atom's value.

XXX thread-safety?  What's that.  Seriously, if two threads race to get the
same atom lazily, they'll interlock in atomizing the value and one will store
the same atom pointer redundantly.  No harm, no foul.

2.  The above laziness does not help defer all chrome function objects from
being deserialized on startup, because each chrome script will be executed in
turn, and each script prolog will JSOP_DEFFUN the top-level functions (ignore
JSOP_CLOSURE and JSOP_{ANON,NAMED}FUNOBJ for the moment, they're rare anyway).

The second level of laziness applies to JSOP_DEFFUN: if it gets its immediate
operand atom and finds the value is a string (this part can and probably should
be done lazily: rt->valueTranscoder will return a true *lazy, causing a later
prolog execution to invoke rt->lazyValueDecoder, which will deserialize just
the function name string, not the function's script), then JSOP_DEFFUN defines
a property with whose name is given by the string, with rt->lazyFunctionGetter
as its getter, and with initial value JSVAL_VOID.

Only if the function is actually called or otherwise used as a value will the
rt->lazyFunctionGetter be invoked.  It should do nothing if *vp is no longer
JSVAL_VOID; otherwise it should deserialize the function's script.  The several
callback implementations will have to keep book on where in the FastLoad file
the function objects are.  That patch, to nsXULElement.cpp is coming next.

/be

Comment 5

[Brendan Eich [:brendan]]

This needs more design time.  If I naively skip function bodies (a la
nsFastLoadPtr's magic, but at the JS XDR level), I'll bloat the serialization
with extra record marks (uint32 length counts followed by opaque data to XDR),
and we won't cut down on reads.  Instead, the XULScript FastLoad code in some
kind of cooperation with the JS XDR code should build a table of contents for
all functions and scripts, which can then be written to the footer and read from
there at startup.

/be

Comment 6

[Brendan Eich [:brendan]]

I hope to get to this before 1.0, which means 0.9.9.

/be

Comment 7

[Brendan Eich [:brendan]]

I'm not going to make 0.9.9 and I wouldn't jam such a large amoung of new code
into 1.0.  This is prime 1.1alpha material.

/be

Comment 8

[Brendan Eich [:brendan]]

No js1.5 linkage here, the lack of engine API extensions needed for this bug to
be fixed properly are not 1.5-stoppers.

/be

Comment 9

[Brendan Eich [:brendan]]

Maybe this will move to 1.2alpha -- maybe it should (we're still fixing xul
proto element fastload bugs).

/be

Comment 10

[Brendan Eich [:brendan]]

I still have the tree where the js/src groundwork was laid for fixing this bug,
but this is not 1.1beta material.

/be

Comment 11

[Brendan Eich [:brendan]]

Moving out, some of these may move to 1.3alpha shortly.

/be

Comment 12

[Brendan Eich [:brendan]]

Fixing TM.

/be

Comment 13

[Brendan Eich [:brendan]]

Wow, I'll have to dust this patch off.

/be

Comment 14

[Brendan Eich [:brendan]]

Not sure when I'll get to this, if ever.

/be

Comment 15

[Mike Schroepfer]

Anything good in here still for Ts improvements?

Comment 16

[Doug Turner (:dougt)]

what mike said?

Comment 17

[Brendan Eich [:brendan]]

This is more ambitious but still stealable. Obviously not high priority to sit on my list for so long. To avoid a chance of dissuading anyone from taking, putting in the nobody@m.o pool. Happy to advise anyone who takes this and can fix it.

/be