Closed
Bug 839973
Opened 11 years ago
Closed 11 years ago
Reduce chunk size for JSCompartment::typeLifoAlloc
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla21
People
(Reporter: n.nethercote, Assigned: n.nethercote)
References
Details
(Whiteboard: [js:t][MemShrink])
Attachments
(1 file)
1.97 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
In bug 804891 we reduced the size of JSCompartment::LIFO_ALLOC_PRIMARY_CHUNK_SIZE -- which is used for both |analysisLifoAlloc| and |typeLifoAlloc| -- from 128 KB to 32 KB, which was a sizeable win on B2G. In this bug I want to reduce the chunk size for |typeLifoAlloc| further, because 32 KB wastes a lot of space. In particular, in a 64-bit build it accounts for 14% of the space uses in a not-yet-loaded tab (bug 681201 comment 80); in a 32-bit build it would account for a higher fraction. Here are the top 10 cases in about:memory after running MemBench50 (http://gregor-wagner.com/tmp/mem50) in a 64-bit browser build. ( 1) 183 (71.5%, 71.5%): 32,768 B (00.00%) ── type-pool ( 2) 23 ( 9.0%, 80.5%): 65,536 B (00.01%) ── type-pool ( 3) 11 ( 4.3%, 84.8%): 98,304 B (00.01%) ── type-pool ( 4) 7 ( 2.7%, 87.5%): 65,536 B (00.01%) ── type-pool [2] ( 5) 5 ( 2.0%, 89.5%): 131,072 B (00.01%) ── type-pool ( 6) 4 ( 1.6%, 91.0%): 294,912 B (00.03%) ── type-pool ( 7) 4 ( 1.6%, 92.6%): 98,304 B (00.01%) ── type-pool [3] ( 8) 2 ( 0.8%, 93.4%): 262,144 B (00.03%) ── type-pool ( 9) 2 ( 0.8%, 94.1%): 196,608 B (00.02%) ── type-pool (10) 2 ( 0.8%, 94.9%): 131,072 B (00.01%) ── type-pool [2] ~71.5% of compartments don't fill the first 32 KB chunk. The total type-pool memory consumption was 16.3 MB. I tried changing it to 8 KB. ( 1) 146 (56.4%, 56.4%): 8,192 B (00.00%) ── type-pool ( 2) 20 ( 7.7%, 64.1%): 24,576 B (00.00%) ── type-pool ( 3) 11 ( 4.2%, 68.3%): 16,384 B (00.00%) ── type-pool ( 4) 10 ( 3.9%, 72.2%): 40,960 B (00.00%) ── type-pool ( 5) 9 ( 3.5%, 75.7%): 16,384 B (00.00%) ── type-pool [2] ( 6) 7 ( 2.7%, 78.4%): 32,768 B (00.00%) ── type-pool ( 7) 6 ( 2.3%, 80.7%): 57,344 B (00.01%) ── type-pool ( 8) 5 ( 1.9%, 82.6%): 81,920 B (00.01%) ── type-pool ( 9) 4 ( 1.5%, 84.2%): 24,576 B (00.00%) ── type-pool [3] (10) 4 ( 1.5%, 85.7%): 73,728 B (00.01%) ── type-pool ~56% of compartments still don't fill the first block. The total type-pool memory consumption dropped to 10.4 MB. I then tried changing it to 4 KB, but the total only dropped to 10.2 MB, so 8 KB seems like the right number.
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #712368 -
Flags: review?(wmccloskey)
Comment on attachment 712368 [details] [diff] [review] Reduce chunk size for JSCompartment::typeLifoAlloc. Review of attachment 712368 [details] [diff] [review]: ----------------------------------------------------------------- This seems fine. I'm moving the typeLifoAlloc to the zone, so it might not matter that much soon.
Attachment #712368 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 3•11 years ago
|
||
Hmm. What else will be moved into the zone? I'm currentlylooking at other sources of compartment overhead, things like: RegExpCompartment, the |debuggees|, CCW table, all the type inference stuff. But I don't want to waste time on them if they're going to be moved.
None of those things you mentioned will be moved at first. typeLifoAlloc is pretty much the only thing I've moved so far that's not directly relevant to the GC. We can reconsider after the initial zone stuff lands. I can pretty much guarantee that the CCW table will have to remain in the compartment, though.
Assignee | ||
Comment 5•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/81bae9ea39ce billm, once zones are done I'd still like the type-pool to use 8 KiB chunks if possible, to avoid regressing the improvement from this bug.
Comment 6•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/81bae9ea39ce
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in
before you can comment on or make changes to this bug.
Description
•