313
edits
Changes
→Garbage collection pauses
An important question is what's an acceptable length for a GC pause. There is no magic value there that will ensure that we maintain 60 FPS: an arbitrarily short pause might make us skip a frame. But there is an important value that will ensure that we don't skip '''more than''' one frame: 1s/60 = 16 ms, so as long as GC pauses are no longer than 16 ms, they don't cause us to skip more than one frame. Thus 16 ms seems like the first goal to aim for, allowing us to maintain an effective 30 FPS when GC occurs.
Incremental GC ({{bug|641025}}) is on track to achieve this goal. The current version keeps mark phase pause times down to 10ms. The [http://hg.mozilla.org/projects/larch Larch] project branch code for IGC has the latest work in this directionlanded to Nightly, and nightly builds but is disabled by default because of nonreproducible memory leaks on our automated tests ([httpwhich we are working on). You can turn it on by going to about://ftpconfig and setting javascript.mozillaoptions.org/pub/mozillamem.org/firefox/tinderbox-builds/larch-linux64/ on ftp]) show already better results than Nightlygc_incremental to true. Potential 10ms+ pauses left over after {{bug|641025}}:
* The sweep phase (mostly because of objects with finalizers, e.g., DOM objects) still runs all at once, and can be 20ms+. Incrementalizing this is much easier that incrementalizing the mark phase and is planned follow-on work.
