Mozilla 2/StatusMeetings/2008-02-06

Mozilla 2 Meeting Details

Discussion

Followup from Tamarin summit
- Interpreter performance
- ActionMonkey stage 4 - unifying the Spidermonkey and tamarin object models

OOM handling
- Need to document our decision more carefully -- are we changing anything for 1.9, or focusing only on moz2?
- This is mainly for moz2
- If mobile needs some better memory-pressure notifications, we might be able to do that for 1.9, but not overarching changes

Notes about OOM handling from last week and hallway conversations:

We don't handle OOM conditions well now
Handling OOM correctly through individual null checks throughout the tree is very tricky and causes/would cause lots of extra code which normally wouldn't be exercised
There are better ways of dealing with OOM:
- For normal allocations (C++ objects), the allocator should never return null.
- If it can't initially allocate, it should perform a GC/cache-free and then reattempt
- We may also be able to keep a reserve block of memory available which will at least get us back to the main event loop (a safe point)
- We should set a low-memory flag which will be dealt with at a safe point
- The goal is to safely get back to the main event loop so that we can close windows/tabs and perform other high-level actions to free memory
- The low-memory flag should have some immediate consequences such as
  - Stopping contentsinks
  - Stopping image decoding
  - Avoiding cacheing anything
- Allocations which result from external data (image buffers) should use a special allocator that can fail

bsmedberg has hounded the owners of the major work items