Closed Bug 839973 Opened 7 years ago Closed 7 years ago

Reduce chunk size for JSCompartment::typeLifoAlloc

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla21

People

(Reporter: njn, Assigned: njn)

References

Details

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

Attachments

(1 file)

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.
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+
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.
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
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.