Reduce chunk size for JSCompartment::typeLifoAlloc

RESOLVED FIXED in mozilla21

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: njn, Assigned: njn)

Tracking

unspecified
mozilla21
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:t][MemShrink])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
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

5 years ago
Created attachment 712368 [details] [diff] [review]
Reduce chunk size for JSCompartment::typeLifoAlloc.
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

5 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

5 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.
https://hg.mozilla.org/mozilla-central/rev/81bae9ea39ce
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.