- status of patches in progress
- performance requirements
- next steps on performance and on memory leaks
Status of Pending CC Code in Bugzilla
- Add cycle collection to RDF datasources: leak regressions remaining?
- Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)
- Make cycle collection suspect all native wrapper roots: backed out.
- Switch nsXPConnect::Traverse to use tracing
- Don't try to collect documents, windows and elements of actively viewed documents
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).
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.