Mozilla 2/StatusMeetings/2008-02-06
From MozillaWiki
< Mozilla 2 | StatusMeetings
« previous week | index | next week »
Mozilla 2 Meeting Details
- Wednesdays - 11:00am Pacific, 2:00pm Eastern, 19:00 UTC
- Mozilla Building S - <script> conference room
- 650-903-0800 or 650-215-1282 x91 Conf# 217 (US/INTL)
- 1-800-707-2533 (pin 369) Conf# 217 (US)
- irc.mozilla.org #mmgc for backchannel
Contents
Discussion
- Followup from Tamarin summit
- Interpreter performance
- ActionMonkey stage 4 - unifying the Spidermonkey and tamarin object models
Action Items
- String analysis - dmandelin is being volunteered
- Dynamic analysis: dump the string data size in UTF16/UTF8
- Dynamic analysis: count the number of conversions between short and wide
- Dynamic analysis: autostring buffer-copy counts (are autostrings worthwhile)?
- How many strings exist *only* for conversion?
- Static analysis: if "AString" were immutable, where would we fail?
- 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
Work List
bsmedberg has hounded the owners of the major work items
Moved to Mozilla 2/Work List