Javascript:SpiderMonkey:ProjectGenerationGarbageCollection

From MozillaWiki
Revision as of 20:12, 28 February 2013 by Terrence (talk | contribs)
Jump to navigation Jump to search

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

  1. Rooting analysis shell green
  2. Exactly rooted shell green
  3. Rooting analysis browser green
  4. Exactly rooted browser
  5. GGC no-jit shell only build on TBPL
  6. GGC on AWFY
  7. GGC faster than Ion on AWFY

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.
    • Milestone 1 - 4
    • evilpie, jonco, Ms2ger, sfink
    • 2 - 3 months
  • JIT integration and optimization.
    • Milestone 6 - 7
    • bhackett
    • 1 - 2 months
  • Preparing the browser to GGC.
    • No Milestone - Postbarrier verifier too slow for TBPL
    • terrence
    • 2 - 3 months
Retrieved from "https://wiki.allizom.org/index.php?title=Javascript:SpiderMonkey:ProjectGenerationGarbageCollection&oldid=532627"