Closed
Bug 497009
Opened 16 years ago
Closed 15 years ago
TM: deallocate LIR buffer after compilation if we don't plan on recompiling a tree
Categories
(Core :: JavaScript Engine, defect, P2)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
fennec | 1.0b3+ | --- |
People
(Reporter: gal, Assigned: graydon)
References
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
2.07 KB,
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•16 years ago
|
||
This will cut the code cache use in half (give or take).
Updated•16 years ago
|
tracking-fennec: --- → 1.0b3+
Comment 2•16 years ago
|
||
My measurements show it will be more like a 70-80% reduction.
![]() |
||
Updated•16 years ago
|
Flags: blocking1.9.2?
Updated•16 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Reporter | ||
Comment 3•15 years ago
|
||
Graydon or I should own this. I will be mostly gone the next 2 weeks, so graydon for now. I will help as needed.
Assignee: general → graydon
Assignee | ||
Comment 4•15 years ago
|
||
This smells a lot like a dupe of 517083, no? If so we should escalate it to P1 blocking, to match this one.
Assignee | ||
Comment 5•15 years ago
|
||
This patch deallocates the LIR after recording, simply by placing it in the tmpAlloc (which is reset post-recording). It also has to clear() the LirBuffer in order to have it forget about the chunk it's part way through carving LIns off.
It appears to make sunspider a teensy bit faster, but doesn't do anything positive for the box2d benchmark in bug 479090. Trace stats show 22-23 flushes before the patch, about the same after. Depending on test noise; it varies substantially (sometimes drops down to 4 flushes, then goes fast).
What's happening here is that the old "mostly LIR" we were seeing in box2d isn't "mostly LIR" anymore. It was mostly skips. We're no longer keeping pure-LIR around, but we're still getting a lot of *aborts*, and an aborted compilation still generates a lot of non-LIR "persistent" objects in the dataAlloc that are essentially junk because the recording aborted. Fragments, Exits, Guards, etc. etc. They used to be skips so they used to look like LIR, but they never really were. They appear to outweigh the "real" LIR moved by this patch by a substantial margin.
I can think of a possible way of fixing this: add a mark/commit/release interface to the allocator. When we start a new recording, mark the start -- save the state of the allocator. When we're sure we want to keep that *increment* of recording-generated material, commit to it. If we abort, release it, rewinding the allocator to the state it was in when we started recording. Currently allocators can't rewind internally, this would make them more like the fancier JS arenas.
If you want, I'll open a fresh bug on that.
Attachment #402514 -
Flags: review?(gal)
Reporter | ||
Comment 6•15 years ago
|
||
I love #5. Thats exactly what the recorder needs.
Assignee | ||
Comment 7•15 years ago
|
||
(In reply to comment #6)
> I love #5. Thats exactly what the recorder needs.
Does that mean r+ on the actual attachment? :)
Reporter | ||
Updated•15 years ago
|
Attachment #402514 -
Flags: review?(gal) → review+
Assignee | ||
Comment 8•15 years ago
|
||
Whiteboard: fixed-in-tracemonkey
Comment 9•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 10•15 years ago
|
||
status1.9.2:
--- → beta1-fixed
Assignee | ||
Updated•15 years ago
|
Flags: in-testsuite-
You need to log in
before you can comment on or make changes to this bug.
Description
•