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•2 years 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•2 years ago
|
| Assignee | ||
Comment 2•2 years ago
|
||
| Assignee | ||
Comment 3•2 years ago
|
||
Depends on D195511
| Assignee | ||
Comment 4•2 years ago
|
||
Depends on D195512
| Assignee | ||
Comment 5•2 years 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•2 years ago
|
||
Depends on D195514
| Assignee | ||
Comment 7•2 years 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•2 years 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•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 10•2 years 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•2 years 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•2 years 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•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 13•2 years ago
|
||
CHUNK_MAP_MADVISED is also used for never-touched pages. Rename it
CHUNK_MAP_CLEAN since it's the clean page cache.
Updated•2 years ago
|
| Assignee | ||
Comment 14•2 years ago
|
||
Also re-write the descriptions of the page kinds.
| Assignee | ||
Comment 15•2 years ago
|
||
Using CHUNK_MAP_FRESH for double purged pages fits better than overloading
the CHUNK_MAP_DECOMMITTED bit with two different semantics.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 16•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 17•2 years ago
|
||
I'm waiting for the code freeze to end before landing this.
| Assignee | ||
Comment 18•2 years 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•2 years ago
|
||
Comment 20•2 years 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•2 years 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•2 years ago
|
||
Description
•