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)
Core
JavaScript Engine
Tracking
()
RESOLVED
DUPLICATE
of bug 678037
People
(Reporter: brendan, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: perf)
Attachments
(1 file, 1 obsolete file)
33.03 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•22 years ago
|
No longer blocks: 67618
Status: NEW → ASSIGNED
Keywords: js1.5,
mozilla0.9.6
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
Reporter | ||
Comment 1•22 years ago
|
||
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
Reporter | ||
Comment 2•22 years ago
|
||
Reporter | ||
Comment 3•22 years ago
|
||
Close but no cigar -- this is work in progress, I'll finish it after 0.9.6 rush hour traffic clears. /be
Keywords: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Reporter | ||
Comment 4•22 years ago
|
||
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
Reporter | ||
Comment 5•22 years ago
|
||
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
Keywords: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Reporter | ||
Comment 6•22 years ago
|
||
I hope to get to this before 1.0, which means 0.9.9. /be
Keywords: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Reporter | ||
Comment 7•22 years ago
|
||
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
Reporter | ||
Updated•22 years ago
|
Keywords: mozilla0.9.9 → mozilla1.1
Reporter | ||
Comment 8•22 years ago
|
||
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
Reporter | ||
Comment 9•22 years ago
|
||
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
Reporter | ||
Comment 10•22 years ago
|
||
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.1 → mozilla1.2
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Reporter | ||
Updated•21 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Reporter | ||
Comment 11•21 years ago
|
||
Moving out, some of these may move to 1.3alpha shortly. /be
Reporter | ||
Comment 13•21 years ago
|
||
Wow, I'll have to dust this patch off. /be
Target Milestone: mozilla1.3beta → mozilla1.5alpha
Reporter | ||
Updated•20 years ago
|
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
Reporter | ||
Comment 14•20 years ago
|
||
Not sure when I'll get to this, if ever. /be
Keywords: mozilla1.2
Target Milestone: mozilla1.6alpha → Future
Reporter | ||
Updated•19 years ago
|
Priority: P1 → P3
Updated•17 years ago
|
QA Contact: pschwartau → general
Comment 15•16 years ago
|
||
Anything good in here still for Ts improvements?
Comment 16•16 years ago
|
||
what mike said?
Updated•14 years ago
|
Severity: normal → enhancement
Priority: P3 → --
Reporter | ||
Comment 17•14 years ago
|
||
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
Updated•12 years ago
|
Target Milestone: Future → mozilla14
Version: Trunk → Other Branch
Updated•12 years ago
|
Target Milestone: mozilla14 → ---
Version: Other Branch → Trunk
Updated•11 years ago
|
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.
Description
•