Closed Bug 107907 Opened 22 years ago Closed 11 years ago

chrome JS should use "delayed FastLoad" for its functions

Categories

(Core :: JavaScript Engine, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 678037

People

(Reporter: brendan, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: perf)

Attachments

(1 file, 1 obsolete file)

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
Blocks: 67618
No longer blocks: 67618
Status: NEW → ASSIGNED
Keywords: js1.5, mozilla0.9.6
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
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
Blocks: 104170
Blocks: 67618
Close but no cigar -- this is work in progress, I'll finish it after 0.9.6 rush
hour traffic clears.

/be
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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
Attachment #56032 - Attachment is obsolete: true
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
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I hope to get to this before 1.0, which means 0.9.9.

/be
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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
Target Milestone: mozilla0.9.9 → mozilla1.1
Keywords: mozilla0.9.9mozilla1.1
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
Keywords: js1.5
Keywords: perf
Maybe this will move to 1.2alpha -- maybe it should (we're still fixing xul
proto element fastload bugs).

/be
Target Milestone: mozilla1.1alpha → mozilla1.1beta
I still have the tree where the js/src groundwork was laid for fixing this bug,
but this is not 1.1beta material.

/be
Keywords: mozilla1.1mozilla1.2
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Moving out, some of these may move to 1.3alpha shortly.

/be
Fixing TM.

/be
Target Milestone: mozilla1.2beta → mozilla1.3beta
Wow, I'll have to dust this patch off.

/be
Target Milestone: mozilla1.3beta → mozilla1.5alpha
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
Not sure when I'll get to this, if ever.

/be
Keywords: mozilla1.2
Target Milestone: mozilla1.6alpha → Future
Priority: P1 → P3
QA Contact: pschwartau → general
Anything good in here still for Ts improvements?
what mike said?
Severity: normal → enhancement
Priority: P3 → --
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
Assignee: brendan → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla14
Version: Trunk → Other Branch
Target Milestone: mozilla14 → ---
Version: Other Branch → Trunk
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.