Trailing guard pages for huge allocations
Categories
(Core :: Memory Allocator, enhancement)
Tracking
()
People
(Reporter: gcp, Assigned: gcp)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 7 obsolete files)
Split off from bug 1446040. Trailing guard pages for normal allocations are relatively easier, and should be able to land ahead of the rest of the work.
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
Assignee | ||
Comment 5•6 years ago
|
||
Changes compared to Matt's original patch:
- Make sure guard pages are always applied on non-Windows systems on realloc.
- Deal with a nasty edge case where we realloc and now there's no more room for a guard.
- Simplify code to remove separate Windows (DECOMMIT) and non-Windows paths.
- apply/remove guard calls the (de)commit function so memory gets tagged.
- Poison zone between the end of the allocation and the start of the guard.
- Fixes for the tests on non-Windows, add test to check for guards when enlarging.
- Tiny optimization to zero only the part of the chunk that will be used.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Comment 7•6 years ago
|
||
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Comment 9•6 years ago
|
||
Depends on D21563
Assignee | ||
Comment 10•6 years ago
|
||
Depends on D21565
Assignee | ||
Comment 11•6 years ago
|
||
Depends on D21566
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 12•6 years ago
|
||
Depends on D21567
Assignee | ||
Comment 13•6 years ago
|
||
Assignee | ||
Comment 14•6 years ago
|
||
Assignee | ||
Comment 15•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Assignee | ||
Comment 17•6 years ago
|
||
Assignee | ||
Comment 18•6 years ago
|
||
Assignee | ||
Comment 19•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 20•6 years ago
|
||
Assignee | ||
Comment 21•6 years ago
|
||
Assignee | ||
Comment 22•6 years ago
|
||
Hopefully the last try push, to check the final performance and memory impact.
Assignee | ||
Comment 23•6 years ago
|
||
I have an implementation for normal pages done in the way glandium suggested, i.e. by making the DECOMMIT logic the general case and then not allocating the final page during the initial run, together with some fixes to prevent that page being included in coalescing/extending. Need to do some more testing first though.
Assignee | ||
Comment 24•6 years ago
|
||
Assignee | ||
Comment 25•6 years ago
|
||
Depends on D23292
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Comment 26•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 27•6 years ago
|
||
Ouch, looks like moz-phab is clueless that the bug has been moved.
Comment 28•6 years ago
|
||
Comment on attachment 9052180 [details]
Bug 1537781 - Guard pages for normal allocations. r=glandium
Revision D24135 was moved to bug 1537781. Setting attachment 9052180 [details] to obsolete.
Comment 29•6 years ago
|
||
Comment on attachment 9047448 [details]
Bug 1537781 - Add a test for guard regions in runs. r=glandium
Revision D21566 was moved to bug 1537781. Setting attachment 9047448 [details] to obsolete.
Comment 30•6 years ago
|
||
glandium, any idea why we saw such a big memory win for this on macOS?
Comment 31•6 years ago
|
||
I think what's happening is that pages_decommit, which now just maps fresh new pages, is better at reducing RSS than when it was using madvise(MADV_FREE).
Updated•6 years ago
|
Description
•