Limit mozjemalloc "logical" page size to 4KB
Categories
(Core :: Memory Allocator, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: pbone, Assigned: pbone)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
Attachments
(6 files, 5 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 |
To ensure that regions can be byte-addressed within runs (Bug 1980047) we need to limit mozjemalloc's page size to 4096 bytes, even on systems where the physical/OS page size is larger. This means separating mozjemalloc's concept of page size into two parts, a "physical" page size and a "logical" page size. OS interfaces like decommitting memory will now have many edge cases that must be handled. This depends on Bug 1921908 which provides a refactoring that will make this change much simpler.
| Assignee | ||
Comment 1•11 months ago
|
||
| Assignee | ||
Comment 2•11 months ago
|
||
Sub-page size classes will be unsed so remove their logic.
| Assignee | ||
Comment 3•10 months ago
|
||
| Assignee | ||
Comment 4•10 months ago
|
||
| Assignee | ||
Comment 5•10 months ago
|
||
Arenas track dirty chunks in a red-black tree ordered by memory address.
Switching this to a list will make it faster to test if an item is in
the list, which is required by the next patch.
Additionally there's no reason this collection needs to be ordered or
support lookups. The ordering by memory address may have some
fragmentation benefits, the new list is operated as a FIFO. Items are
appended at the tail when they get their first dirty page, and removed
from the head as they're purged.
| Assignee | ||
Comment 6•10 months ago
|
||
Currently a dirty chunk (that's a chunk with at least one dirty page)
must:
- Be in mChunksDirty
- Be busy pruging by another thread.
The next change will allow it so that chunks with a non-zero mNumDirty
might not be in the dirty chunks list because its impossible to purge
their pages. Therefore in this change we relax the above assumption.
Updated•10 months ago
|
Comment 7•10 months ago
|
||
Comment on attachment 9510759 [details]
WIP: Bug 1980056 - pt 1. Correct a comment
Revision D263334 was moved to bug 1987055. Setting attachment 9510759 [details] to obsolete.
Comment 8•10 months ago
|
||
Comment on attachment 9510760 [details]
WIP: Bug 1980056 - pt 2. Merge purge results, ReachedThreshold and Busy
Revision D263335 was moved to bug 1987055. Setting attachment 9510760 [details] to obsolete.
Comment 9•10 months ago
|
||
Comment on attachment 9510761 [details]
WIP: Bug 1980056 - pt 3. Change the dirty chunks tree to a list
Revision D263336 was moved to bug 1987055. Setting attachment 9510761 [details] to obsolete.
Comment 10•10 months ago
|
||
Comment on attachment 9510762 [details]
WIP: Bug 1980056 - pt 4. mChunksDirty doesn't always track all dirty chunks
Revision D263337 was moved to bug 1987055. Setting attachment 9510762 [details] to obsolete.
Comment 11•10 months ago
|
||
Comment on attachment 9503950 [details]
WIP: Bug 1980056 - pt 5. Mozjemalloc can now use page sizes smaller than the real size
Revision D259219 was moved to bug 1987055. Setting attachment 9503950 [details] to obsolete.
| Assignee | ||
Comment 12•10 months ago
|
||
Updated•9 months ago
|
Updated•9 months ago
|
Comment 13•5 months ago
|
||
Comment 14•5 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4b4fb5fd1f38
https://hg.mozilla.org/mozilla-central/rev/007298d99ba4
Comment 15•5 months ago
|
||
Comment 16•5 months ago
|
||
Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/cdf9cf902cdd
| Assignee | ||
Updated•5 months ago
|
Updated•5 months ago
|
| Assignee | ||
Comment 17•5 months ago
|
||
Huge allocations will always be rounded to real pages.
| Assignee | ||
Comment 18•5 months ago
|
||
The test uses page size to calculate the size of the chunk header for
testing jemalloc_ptr_info. Using real page size is correct for finding
the size of the chunk header.
| Assignee | ||
Comment 19•5 months ago
|
||
Realloc of huge allocations used the wrong page size to determine if
they're safe to do in-place. This patch fixes this.
| Assignee | ||
Comment 20•5 months ago
|
||
When the allocator touches previously-madvised memory it must clear
madvised bits of trailing pages to keep them aligned with
real pages.
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Comment 21•5 months ago
|
||
Comment 22•5 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/94615f8bf640
https://hg.mozilla.org/mozilla-central/rev/4d3ec02a3564
https://hg.mozilla.org/mozilla-central/rev/48be5ff02dcf
https://hg.mozilla.org/mozilla-central/rev/c88c117b2663
https://hg.mozilla.org/mozilla-central/rev/97bf4a05fb87
https://hg.mozilla.org/mozilla-central/rev/664ac9f557d1
Updated•4 months ago
|
Updated•4 months ago
|
Description
•