CycleCollector/CCStatus-2007-04-27

From MozillaWiki
Jump to: navigation, search

« previous meeting | index | next meeting »

Agenda

  • status of patches in progress
  • performance requirements
  • next steps on performance and on memory leaks

Status of Pending CC Code in Bugzilla

Performance requirements

On Monday David Baron suggested that a performance requirements for the collection pauses is that getting the cycle collection pauses (which include a JS garbage collection) to somewhere around 2 times the length of the JS garbage collection pauses prior to the cycle collector landing would constitute reasonable performance. Is this sufficiently fast? Is it achievable? (We knew we'd take some performance and heap size regressions from the cycle collector; the question is what regressions are acceptable.)

Next steps on leaks

Next steps: Wait for above patches (first 4 of 5) to land, then test more.

Next steps on performance (pauses)

bug 378514 was around a 30% performance improvement in the duration of pauses using one sample workload (and that was with an accidental extra call to canonicalize() that was taken out before landing).

Do we know how much bug 378595 helped and how much bug 378987 and doing less XPCCallContext construction (maybe in bug 377884) will help?

Next steps: wait for bug 378987 to land, and for peterv to fix XPCCallContext construction performance problem in nsXPConnect::Traverse (either in bug 368774 or a new bug to be filed). Then measure and profile collection pauses again.

Next steps on performance (general degradation)

How important is the overall performance degradation (e.g., AddRef/Release overhead)?

Next steps: We're going to hit the general perf bugs in the usual 1.9 triage. We'll consider asking people to retest any items as necessary.