Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 95: Line 95:
</ul>
</ul>
<h1> Parallelizable Sub-tasks </h1>
<h1> Parallelizable Sub-tasks </h1>
<h2> Exactly rooting the browser. </h2>
<ul>
<h2> JIT integration and optimization. </h2>
<li> Exactly rooting the browser. </li>
<h2> Preparing the browser to GGC. </h2>
<li> JIT integration and optimization. </li>
<li> Preparing the browser to GGC. </li>
</ul>

Revision as of 20:04, 28 February 2013

Wiki conversion of original Google Document: https://docs.google.com/a/jamsni.com/document/d/1-GZ8F0ZabvdpCnRQaecId0yuu4QFYr5pAvnRC_KFchc/edit


Objective

Implement Generational Garbage collection in Spider Monkey. <Some goal based off V8 performance delta % on Earley Boyer benchmark>

Accountable: Naveed
Responsible: Terrence, Steve, Jon, Nicholas, evilpie and Ms2ger
Consulted: bhackett billm
Informed: Product Marketing

Tracking Bug: [meta] Implement generational garbage collection - bug 619558

Milestones

Steps

Exact Rooting done in JS Shell bug 753203

12 weeks started

JIT Integration with post barriers - 4 weeks, parallelized

Generational Garbage Collection in the Shell

  • Implement prototype algorithm (terrence) - 1 week
  • This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
  • Re-implement HashTable rekeying
    • We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
    • at least part of this is bug 726687

Exactly Root the Browser bug 831379 - 10 weeks

  • This is a potential milestone: we would turn on exact rooting for release FF at this point. We would not get a performance boost from this (necessarily), but it would lock in our work to this point.

Performance Tuning - 4 weeks (This should probably start asap)

  • Implement a Nursery bug 706885 - 1 week
  • Test against V8 Earley-Boyer benchmark.
    • Also v8 deltablue, raytrace
  • We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf bug 759585 - 6 weeks
  • Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable bug 831886 (bhackett) - done

Make the Post Barrier Verifier Green in the browser bug 764882

  • Investigate how long it will take to do generational barriers - 1 week
  • We may need to rewrite the maps in xpconnect and the browser in terms of HashTable: this could be a bunch of work.
  • Make JS_IsAboutToBeFinalized indirect bug 765432 - 10 weeks

Other

  • Should we establish a new benchmark specifically for GGC. (sfink votes yes)
    • What would it measure? there are multiple goals, e.g. throughput/MMU/pause time
    • Should we make it a public benchmark?
    • What workloads should we consider?
    • compartmental GC very important to us, not necessarily applicable to other implementations
    • allocation rate (broken down into live vs garbage), steady behavior vs swapping between allocation + computation modes, etc.
  • How can we keep our advantage on Splay benchmark
    • possible to do with TI --- look at types of objects promoted from nursery to major heap, eventually start allocating them directly in the major heap
  • Compacting GC - Revisit in Febuary/March - 1 Month
    • Delayed until exact rooting is fully done. We can add this in if we have time in the schedule that we cannot parallelize.

Risks

  • Team is responsible for many top crashers
  • External rooting API has not been designed
  • GGC algorithm has not been decided on - it may not be faster
  • JSD1 exact rooting is lurking

Parallelizable Sub-tasks

  • Exactly rooting the browser.
  • JIT integration and optimization.
  • Preparing the browser to GGC.
Retrieved from "https://wiki.allizom.org/index.php?title=Javascript:SpiderMonkey:ProjectGenerationGarbageCollection&oldid=532616"