Mozilla 2/StatusMeetings/2008-02-06: Difference between revisions

Latest revision as of 19:30, 6 February 2008

Mozilla 2 Meeting Details

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

@@ Line 29: / Line 29: @@
 ** 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
 == Work List ==