Try to reduce VirtualAlloc calls in mozjemalloc
Categories
(Core :: Memory Allocator, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: pbone, Assigned: pbone)
References
(Blocks 2 open bugs)
Details
Attachments
(10 files, 2 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Jeff Muizelaar found that mozjemalloc's allocation patterns can cause us to make very frequent calls to VirtualAlloc, at least more frequent that Chrome does.
He wrote:
pbone: another related thing that I saw today: During a run of 10 iterations of TodoMVC-> jquery we're doing 20x the number VirtualAllocs/VirtualFrees that Chrome is
[they're comming from] splitRun [see] https://share.firefox.dev/45scxBe
Comment 1•1 year ago
|
||
Off the top of my head, the only way to reduce the number of these VirtualAllocs would be to have something akin to the double purge we have on mac, and in any case, that will have an impact on RSS, since these VirtualAllocs are there to reduce memory usage (they decommit/recommit memory).
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 2•1 year ago
|
||
Assignee | ||
Comment 3•1 year ago
|
||
Depends on D195511
Assignee | ||
Comment 4•1 year ago
|
||
Depends on D195512
Assignee | ||
Comment 5•1 year ago
|
||
This breaks the old invariant that there are no committed pages that aren't
either allocated or dirty. There is now also new code in DeallocChunk that
counts the number of "fresh" committed pages and adjusts mStats.committed.
Depends on D195513
Assignee | ||
Comment 6•1 year ago
|
||
Depends on D195514
Assignee | ||
Comment 7•10 months ago
|
||
This is a 2-3% performance win if we don't mind a 13% memory increase.
I'll keep working on it.
Assignee | ||
Comment 8•10 months ago
|
||
Actually the difference is in how the page cache is measured as a kind of explicit memory. But these pages aren't paged in and you can see that there's no difference to resident memory. So I think the memory usage difference is actually negligible.
Assignee | ||
Comment 9•10 months ago
|
||
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Assignee | ||
Comment 10•10 months ago
|
||
The decommit logic is now only used when MALLOC_DECOMMIT is defined. Now
the CHUNK_MAP_MADVISED bit is cleared when the page is initialised avoiding
leaving the chunk map in an inconsistent state if pages_commit failes and
simplifying some logic.
These changes will make the next patch simpler.
Assignee | ||
Comment 11•10 months ago
|
||
This memory was previously measured as part of committed memory. However
since it probably has no physical page allocated it's more correct to count
it as clean. This has the side effect of now including it in the page cache
and therefore decisions like when to purge memory will change.
Assignee | ||
Comment 12•10 months ago
|
||
When recording the memory usage properly the benchmarks are much better: https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=733e18745b8bdfe487c9da631453a48c75154f02&newProject=try&newRevision=88392f200d142403cd0705f57c9a096fdb72c99f&framework=13&page=1 Click through to the awsy results too.
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Assignee | ||
Comment 13•9 months ago
|
||
CHUNK_MAP_MADVISED is also used for never-touched pages. Rename it
CHUNK_MAP_CLEAN since it's the clean page cache.
Updated•9 months ago
|
Assignee | ||
Comment 14•9 months ago
|
||
Also re-write the descriptions of the page kinds.
Assignee | ||
Comment 15•9 months ago
|
||
Using CHUNK_MAP_FRESH for double purged pages fits better than overloading
the CHUNK_MAP_DECOMMITTED bit with two different semantics.
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Assignee | ||
Comment 16•9 months ago
|
||
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 17•8 months ago
|
||
I'm waiting for the code freeze to end before landing this.
Assignee | ||
Comment 18•8 months ago
|
||
Here's the latest performance comparison:
There are tests in both "browsertime" and "awsy". In the awsy tests the big difference in explicit memory is a change in how we measure memory - not a real memory difference, for that please look at "resident".
Comment 19•8 months ago
|
||
Comment 20•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7a09b357080f
https://hg.mozilla.org/mozilla-central/rev/83e751e19af4
https://hg.mozilla.org/mozilla-central/rev/fe61be13535d
https://hg.mozilla.org/mozilla-central/rev/1a70135ddbda
https://hg.mozilla.org/mozilla-central/rev/afe7c24ca50e
https://hg.mozilla.org/mozilla-central/rev/52f8506f3bfb
https://hg.mozilla.org/mozilla-central/rev/f335f70a1c14
https://hg.mozilla.org/mozilla-central/rev/82252f397be4
https://hg.mozilla.org/mozilla-central/rev/86d16de09fc9
https://hg.mozilla.org/mozilla-central/rev/37720af4970f
Comment 21•8 months ago
|
||
Some improvements from AWFY-SP2
5% improvement jqueryTodoMVC
4.2% on Vanilla-ES2015-Babel-Webpack-TodoMVC
3.5% on Vanilla-ES2015-TodoMVC
Comment 22•8 months ago
|
||
Description
•