Mozilla 2/Memory: Difference between revisions
Jump to navigation
Jump to search
(memory writeup) |
(link up OOM tracking bug) |
||
| Line 6: | Line 6: | ||
= Status = | = Status = | ||
Design | Design and implementation have begun. | ||
OOM tracking: {{bug|427099}} | |||
= Overview and Motivations = | = Overview and Motivations = | ||
Revision as of 19:57, 4 April 2008
Owners
- bsmedberg, jasone
- (stuart, jorendorff)
Status
Design and implementation have begun.
OOM tracking: bug 427099
Overview and Motivations
- Simplify the Mozilla codebase and avoid untested error paths by assuming that most allocations do not fail.
- add garbage collection support to jemalloc to support XPCOMGC.
- Design and test fallback mechanisms at OOM or close-to-OOM for freeing caches, closing tabs, etc
Risks and Assumptions
Risks are that we actually will hit OOM and abort, mainly on small devices.
Schedule and Milestones
Track I:
- Provide an alternate malloc_can_fail API - easy
- Make large allocations use the alternate API - need analysis?
- Automatic rewriting to remove unnecessary OOM checks - dmandelin?
Track II:
- Add GC API support to jemalloc - need date estimate
References
- Initial discussion of APIs needed for garbage collection is ongoing at GC_API.
- OOM handling meeting notes: Mozilla 2/StatusMeetings/2008-02-06
Note that this is not a blocker for XPCOMGC work, because MMgc works now; it's just likely that our memory usage will be much better with a jemalloc backend.