Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Objective: cleaner formatting)
No edit summary
Line 1: Line 1:
Wiki conversion of original Google Document: https://docs.google.com/a/jamsni.com/document/d/1-GZ8F0ZabvdpCnRQaecId0yuu4QFYr5pAvnRC_KFchc/edit
<p>Wiki conversion of original Google Document: https://docs.google.com/a/jamsni.com/document/d/1-GZ8F0ZabvdpCnRQaecId0yuu4QFYr5pAvnRC_KFchc/edit
 
</p><p><br />
 
</p>
<h1> Objective </h1>
<h1> Objective </h1>
<p>Implement Generational Garbage collection in Spider Monkey. &lt;Some goal based off V8 performance delta&#160;% on Earley Boyer benchmark&gt;
<p>Implement Generational Garbage collection in Spider Monkey. &lt;Some goal based off V8 performance delta&#160;% on Earley Boyer benchmark&gt;</p>
</p><p><b>Accountable</b>: Naveed<br />
<b>Accountable</b>: Naveed<br />
<b>Responsible</b>: Terrence, Steve, Jon, Nicholas, evilpie and Ms2ger<br />
<b>Responsible</b>: Terrence, Steve, Jon, Nicholas, evilpie and Ms2ger<br />
<b>Consulted</b>: bhackett billm<br />
<b>Consulted</b>: bhackett billm<br />
<b>Informed</b>: Product Marketing<br />
<b>Informed</b>: Product Marketing<br />
</p><p><b>Tracking Bug:</b> [meta] Implement generational garbage collection - <span class="fck_mw_template">{{bug|619558}}</span>
<br/>
<b>Tracking Bug:</b> [meta] Implement generational garbage collection - <span class="fck_mw_template"><span class="fck_mw_template"><span class="fck_mw_template">{{bug|619558}}</span></span></span>
<h2> Steps </h2>
<h3> Exact Rooting done in JS Shell <span class="fck_mw_template"><span class="fck_mw_template">{{bug|753203}}</span></span> </h3>
<p>12 weeks started
</p>
<ul><li> Rooting Analysis on TinderBox (sfink) - done
<ul><li> Still need to unhide it for inbound - get it green, keep it green
</li></ul>
</li><li> Get the root analysis build green - two weeks?
<ul><li> Get jit-tests green <span class="fck_mw_template"><span class="fck_mw_template">{{bug|745742}}</span></span>
</li><li> Get js ref tests green
</li><li> Get jsapi-tests green <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831376}}</span></span>
</li></ul>
</li><li> Rooting analysis fuzz bugs <span class="fck_mw_template"><span class="fck_mw_template">{{bug|773746}}</span></span>
<ul><li> Rely on static analysis to make this not be a whack-a-mole game
</li></ul>
</li><li> Remove E4X - done
</li><li> Do something about JSD
</li><li> Add exact roots to stack structures - 2 weeks
</li><li> AddRoot/RemoveRoot for Heap structures - 4 weeks
</li><li> Static code analysis <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831409}}</span></span>
<ul><li> Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
</li><li> Optimize all discovered over-rooting (~100)
</li><li> Automate static analysis <span class="fck_mw_template"><span class="fck_mw_template">{{bug|834912}}</span></span> (sfink)
<ul><li> Need a server (dm-sixgill01?)
</li><li> http://people.mozilla.org/~sfink/data/rootingHazards.txt
</li><li> http://people.mozilla.org/~sfink/data/gcFunctions.txt
</li><li> http://people.mozilla.org/~sfink/data/allFunctions.txt
</li></ul>
</li></ul>
</li></ul>
<h3> JIT Integration with post barriers - 4 weeks, parallelized </h3>
<ul><li> IonMonkey <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831506}}</span></span> - 1 week (bhackett)
</li><li> JaegerMonkey <span class="fck_mw_template"><span class="fck_mw_template">{{bug|764876}}</span></span> - 2 days (bhackett)
</li><li> Baseline JIT <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831507}}</span></span> - &lt;ask jandem/djvj for an estimate&gt;
</li></ul>
<h3> Generational Garbage Collection in the Shell </h3>
<ul><li> Implement prototype algorithm (terrence) - 1 week
</li><li> This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
</li><li> Re-implement HashTable rekeying
<ul><li> We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
</li><li> at least part of this is <span class="fck_mw_template"><span class="fck_mw_template">{{bug|726687}}</span></span>
</li></ul>
</li></ul>
<h3> Exactly Root the Browser <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831379}}</span></span> - 10 weeks </h3>
<ul><li> 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.
</li></ul>
<h3> Performance Tuning - 4 weeks (This should probably start asap) </h3>
<ul><li> Implement a Nursery <span class="fck_mw_template"><span class="fck_mw_template">{{bug|706885}}</span></span> - 1 week
</li><li> Test against V8 Earley-Boyer benchmark.
<ul><li> Also v8 deltablue, raytrace
</li></ul>
</li><li> We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf <span class="fck_mw_template"><span class="fck_mw_template">{{bug|759585}}</span></span> - 6 weeks
</li><li> Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable <span class="fck_mw_template"><span class="fck_mw_template">{{bug|831886}}</span></span> (bhackett) - done
</li></ul>
<h3> Make the Post Barrier Verifier Green in the browser <span class="fck_mw_template"><span class="fck_mw_template">{{bug|764882}}</span></span> </h3>
<ul><li> Investigate how long it will take to do generational barriers - 1 week
</li><li> We may need to rewrite the maps in xpconnect and the browser in terms of HashTable: this could be a bunch of work.
</li><li> Make JS_IsAboutToBeFinalized indirect <span class="fck_mw_template"><span class="fck_mw_template">{{bug|765432}}</span></span> - 10 weeks
</li></ul>
<h2> Other </h2>
<ul><li> Should we establish a new benchmark specifically for GGC. (sfink votes yes)
<ul><li> What would it measure? there are multiple goals, e.g. throughput/MMU/pause time
</li><li> Should we make it a public benchmark?
</li><li> What workloads should we consider?
</li><li> compartmental GC very important to us, not necessarily applicable to other implementations
</li><li> allocation rate (broken down into live vs garbage), steady behavior vs swapping between allocation + computation modes, etc.
</li></ul>
</li></ul>
<ul><li> How can we keep our advantage on Splay benchmark
<ul><li> 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
</li></ul>
</li></ul>
<ul><li> Compacting GC - Revisit in Febuary/March - 1 Month
<ul><li> Delayed until exact rooting is fully done. We can add this in if we have time in the schedule that we cannot parallelize.
</li></ul>
</li></ul>
<h2> Risks </h2>
<ul><li> Team is responsible for many top crashers
</li></ul>
<ul><li> External rooting API has not been designed
</li></ul>
<ul><li> GGC algorithm has not been decided on - it may not be faster
</li></ul>
<ul><li> JSD1 exact rooting is lurking
</li></ul>
<p><br />
</p>
</p>
== Steps ==
=== Exact Rooting done in JS Shell {{bug|753203}} ===
12 weeks started
* Rooting Analysis on TinderBox (sfink) - done
** Still need to unhide it for inbound - get it green, keep it green
* Get the root analysis build green - two weeks?
** Get jit-tests green {{bug|745742}}
** Get js ref tests green
** Get jsapi-tests green {{bug|831376}}
* Rooting analysis fuzz bugs {{bug|773746}}
** Rely on static analysis to make this not be a whack-a-mole game
* Remove E4X - done
* Do something about JSD
* Add exact roots to stack structures - 2 weeks
* AddRoot/RemoveRoot for Heap structures - 4 weeks
* Static code analysis {{bug|831409}}
** Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
** Optimize all discovered over-rooting (~100)
** Automate static analysis {{bug|834912}} (sfink)
*** Need a server (dm-sixgill01?)
*** http://people.mozilla.org/~sfink/data/rootingHazards.txt
*** http://people.mozilla.org/~sfink/data/gcFunctions.txt
*** http://people.mozilla.org/~sfink/data/allFunctions.txt
=== JIT Integration with post barriers - 4 weeks, parallelized ===
* IonMonkey {{bug|831506}} - 1 week (bhackett)
* JaegerMonkey {{bug|764876}} - 2 days (bhackett)
* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate>
=== 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

Revision as of 19:13, 16 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

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


Retrieved from "https://wiki.allizom.org/index.php?title=Javascript:SpiderMonkey:ProjectGenerationGarbageCollection&oldid=521254"