Mozilla 2/StatusMeetings/2008-02-06

From MozillaWiki
Jump to: navigation, search

« 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)
  • #mmgc for backchannel


  • 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