1843998 - Investigate adjusting structure sizes to amortise costs in jemalloc

Status: NEW

(Core :: Memory Allocator, task)

Description

[Paul Bone [:pbone]]

jemalloc picks run sizes based on what will fit neatly in memory without creating excess fragmentation. AFAIK there's no optimisation of avoiding slow paths like creating new runs. Would it be possible to change sizes of runs (or other structures) to amortise costs of those slow paths? Will that increase fragmentation?

See Bug 1843932

Comment 1

[Paul Bone [:pbone]]

We can set a lower-bound on the number of cells per run. The highest lower-bound that still works (given other structure sizes) is 35. So testing that tells us the most we can possibly achieve by adjusting this, a theoretical maximum. I like to test values like this because it's a quick test if it's worth continuning or to give up. If this didn't show interesting results then nothing would. But if it is interesting then it may be worth testing more conservative values.

https://treeherder.mozilla.org/jobs?repo=try&revision=3b9351c72b815ed0d78e0db979b033e07ce957ed

Subtests look nice: https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=3b9351c72b815ed0d78e0db979b033e07ce957ed&originalSignature=4701848&newSignature=4701848&framework=13&application=firefox&originalRevision=5a75c05ba02e98eab3e55fceecce3bec9d1187a4&page=1&showOnlyConfident=1
Windows sp3: 0.63% better, 4.27 confidence
Windows resident base: 0.86% worse, 7.72 confidence
Windows resident tp6: 1.16% worse, 1.57 confidence

But explicit memory is bad, why is it affected but not resident? Probably because of how mozjemalloc measures overhead.