Closed
Bug 481793
Opened 16 years ago
Closed 16 years ago
TM: Better coordination of nested tree recording
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: gal, Assigned: gal)
References
Details
(Keywords: verified1.9.1, Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
13.94 KB,
patch
|
dmandelin
:
review+
|
Details | Diff | Splinter Review |
The attached patch improves the coordination of nested tree recording. When we abort an outer recorder because we wait for a) an inner tree to be compiled b) an inner tree to finish growing a branch or c) an inner tree to grow around its inner tree, remember in that recording the loop header of the loop we just aborted, and in case that compilation succeeds, permit all peer fragments attached to that particular loop header to compile at least one more time. If the location was permanently blacklisted, undo the blacklisting. With this patch we can drop BL_ATTEMPTS to 2 (from 6) and still get proper tree construction for our favorite trouble makers fasta and fannkuch. This wins about 10ms on SS and should overall reduce the recording overhead in cases where we abort recording repeatedly since we blacklist faster now.
Assignee | ||
Comment 1•16 years ago
|
||
Assignee: general → gal
Assignee | ||
Updated•16 years ago
|
Attachment #365815 -
Flags: review?(dmandelin)
Assignee | ||
Comment 2•16 years ago
|
||
Note also this subtle change:
int32_t& hits = c->hits();
if (outer || hits++ >= HOTEXIT && hits <= HOTEXIT+MAXEXIT) {
/* start tracing secondary trace from this point */
c->lirbuf = f->lirbuf;
dmandelin identified this problem. We used to wait for HOTEXIT when an already recorded inner tree tried to grow a branch while we were recording the outer tree. This caused repeated recording aborts. If we already abort recording because of such an inner tree growth, we of course want to immediately record no matter what hotexit says.
Comment 3•16 years ago
|
||
Comment on attachment 365815 [details] [diff] [review]
patch
Looks good to me. I'll do my own SS test on it a bit later (since my machine tends to be different) but I think it's good to land based on what we know.
Attachment #365815 -
Flags: review?(dmandelin) → review+
Assignee | ||
Comment 4•16 years ago
|
||
Whiteboard: fixed-in-tracemonkey
Comment 5•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 6•16 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/3fb1b5d6dc60
/cvsroot/mozilla/js/tests/js1_8_1/trace/trace-test.js,v <-- trace-test.js
new revision: 1.13; previous revision: 1.12
Flags: in-testsuite+
Comment 7•16 years ago
|
||
Keywords: fixed1.9.1
Comment 8•16 years ago
|
||
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•