Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Undo revision 505634 by Naveed (talk))
Line 1: Line 1:
== Objective ==
<h2> Objective </h2>
Implement Generational Garbage collection in Spider Monkey. <Some goal based off V8 performance delta % on Earley Boyer benchmark>
<p>Implement Generational Garbage collection in Spider Monkey. &lt;Some goal based off V8 performance delta&#160;% on Earley Boyer benchmark&gt;
 
</p>
* Accountable: Naveed
<ul><li> Accountable: Naveed
 
</li></ul>
* Responsible: Terrence, Steve, Jon, Nicholas, and evilpie Ms2ger
<ul><li> Responsible: Terrence, Steve, Jon, Nicholas, and evilpie Ms2ger
 
</li></ul>
* Consulted: bhackett billm
<ul><li> Consulted: bhackett billm
 
</li></ul>
* Informed: Product Marketing
<ul><li> Informed: Product Marketing
 
</li></ul>
Generational GC - [https://bugzilla.mozilla.org/show_bug.cgi?id=619558 Bug 619558]
<p>Generational GC - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=619558">Bug 619558</a>
 
</p>
<h2> Steps </h2>
<h2> Steps </h2>
<ol>
<p>Exact Rooting done in JS Shell <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=753203">Bug 753203</a> - 12 weeks started
<li>Exact Rooting done in JS Shell &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=753203"&gt;Bug 753203&lt;/a&gt; - 12 weeks started
<ol>
<li>Rooting Analysis on TinderBox (sfink) - 3 weeks
<ol>
<li>patch is ready for review, would fix the problem with some pushes not getting builds
<li>fix up other stuff broken by above change
<li>fix up other stuff broken by above change
<li>patch would fix last remaining problem with getting it on Try server
<li>Unhide it for inbound - keep it green
</ol>
</ol>
</ol>
<p><br />
</p>
<p>Exact Rooting done in JS Shell &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=753203"&gt;Bug 753203&lt;/a&gt; - 12 weeks started
</p><p>Rooting Analysis on TinderBox (sfink) - 3 weeks
</p><p>Rooting Analysis on TinderBox (sfink) - 3 weeks
</p><p>patch is ready for review, would fix the problem with some pushes not getting builds
</p><p>patch is ready for review, would fix the problem with some pushes not getting builds
Line 35: Line 20:
</p><p>Unhide it for inbound - keep it green
</p><p>Unhide it for inbound - keep it green
</p><p>Get the root analysis build green - two weeks?
</p><p>Get the root analysis build green - two weeks?
</p><p>Get jit-tests green &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=745742"&gt;Bug 745742&lt;/a&gt; - 2 days
</p><p>Get jit-tests green <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=745742">Bug 745742</a> - 2 days
</p><p>Get js ref tests green  
</p><p>Get js ref tests green  
</p><p>Get jsapi-tests green &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831376"&gt;Bug 831376&lt;/a&gt;
</p><p>Get jsapi-tests green <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831376">Bug 831376</a>
</p><p>Fuzzer coverage of code &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=773746"&gt;Bug 773746&lt;/a&gt;
</p><p>Fuzzer coverage of code <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=773746">Bug 773746</a>
</p><p>rely on static analysis to make this not be a whack-a-mole game
</p><p>rely on static analysis to make this not be a whack-a-mole game
</p><p>Remove E4X  
</p><p>Remove E4X  
Line 44: Line 29:
</p><p>Add exact roots to stack structures - 2 weeks
</p><p>Add exact roots to stack structures - 2 weeks
</p><p>AddRoot/RemoveRoot for Heap structures - 4 weeks
</p><p>AddRoot/RemoveRoot for Heap structures - 4 weeks
</p><p>Static code analysis &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831409"&gt;Bug 831409&lt;/a&gt;
</p><p>Static code analysis <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831409">Bug 831409</a>
</p><p>Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
</p><p>Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
</p><p>Optimize all discovered over-rooting (~100)
</p><p>Optimize all discovered over-rooting (~100)
Line 52: Line 37:
</p><p>http://people.mozilla.org/~bhackett/gcFunctions.html
</p><p>http://people.mozilla.org/~bhackett/gcFunctions.html
</p><p><br />
</p><p><br />
<p>JIT Integration with post barriers - 4 weeks, parallelized
JIT Integration with post barriers - 4 weeks, parallelized
</p>
</p><p>IonMonkey <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831506">Bug 831506</a> - 1 week (bhackett)
</p><p>IonMonkey &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831506"&gt;Bug 831506&lt;/a&gt; - 1 week (bhackett)
</p><p>JaegerMonkey <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764876">Bug 764876</a> - 2 days (bhackett)
</p><p>JaegerMonkey &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764876"&gt;Bug 764876&lt;/a&gt; - 2 days (bhackett)
</p><p>Baseline JIT <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831507">Bug 831507</a> - &lt;ask jandem/djvj for an estimate&gt;
</p><p>Baseline JIT &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831507"&gt;Bug 831507&lt;/a&gt; - &lt;ask jandem/djvj for an estimate&gt;
</p><p>Generation Garbage Collection in the Shell
</p><p>Generation Garbage Collection in the Shell
</p><p>Implement prototype algorithm (terrence) - 1 week
</p><p>Implement prototype algorithm (terrence) - 1 week
</p><p>This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
</p><p>This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
</p><p>Exactly Root the Browser &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831379"&gt;Bug 831379&lt;/a&gt; - 10 weeks
</p><p>Exactly Root the Browser <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831379">Bug 831379</a> - 10 weeks
</p><p>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.
</p><p>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.
</p><p>Performance Tuning - 4 weeks (This should probably start asap)
</p><p>Performance Tuning - 4 weeks (This should probably start asap)
</p><p>Test against V8 Earley-Boyer benchmark.
</p><p>Test against V8 Earley-Boyer benchmark.
</p><p>Also v8 deltablue, raytrace
</p><p>Also v8 deltablue, raytrace
</p><p>Implement a Nursery &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=706885"&gt;Bug 706885&lt;/a&gt; - 1 week
</p><p>Implement a Nursery <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=706885">Bug 706885</a> - 1 week
</p><p>We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks
</p><p>We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks
</p><p>Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable -&#160;??? weeks (start early) (bhackett)
</p><p>Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable -&#160;??? weeks (start early) (bhackett)
</p><p>Re-implement HashTable rekeying
</p><p>Re-implement HashTable rekeying
</p><p>We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
</p><p>We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
</p><p>Make the Post Barrier Verifier Green in the browser &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764882"&gt;Bug 764882&lt;/a&gt;
</p><p>Make the Post Barrier Verifier Green in the browser <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764882">Bug 764882</a>
</p><p>Investigate how long it will take to do generational barriers - 1 week
</p><p>Investigate how long it will take to do generational barriers - 1 week
</p><p>We may need to rewrite the maps in xpconnect and the browser in terms of HashTable: this could be a bunch of work.  
</p><p>We may need to rewrite the maps in xpconnect and the browser in terms of HashTable: this could be a bunch of work.  
<p>Make JS_IsAboutToBeFinalized indirect &lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=765432"&gt;Bug 765432&lt;/a&gt; - 10 weeks
Make JS_IsAboutToBeFinalized indirect <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=765432">Bug 765432</a> - 10 weeks
</p>
</p>
</p>
<h2> Other </h2>
 
<p>Should we establish a new  benchmark specifically for GGC. (sfink votes yes)
== Other ==
</p><p>What would it measure? there are multiple goals, e.g. throughput/MMU/pause time
 
</p><p>Should we make it a public benchmark?
Should we establish a new  benchmark specifically for GGC. (sfink votes yes)
</p><p>What workloads should we consider?
 
</p><p>compartmental GC very important to us, not necessarily applicable to other implementations
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.
allocation rate (broken down into live vs garbage), steady behavior vs swapping between allocation + computation modes, etc.
 
</p><p>How can we keep our advantage on Splay benchmark
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
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
 
</p><p>Compacting GC - Revisit in Febuary/March - 1 Month
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.
Delayed until exact rooting is fully done. We can add this in if we have time in the schedule that we cannot parallelize.
 
</p>
== Risks ==
<h2> Risks </h2>
 
<ul><li> Team is responsible for many top crashers
* Team is responsible for many top crashers
</li></ul>
 
<ul><li> External rooting API has not been designed  
* External rooting API has not been designed  
</li></ul>
 
<ul><li> GGC algorithm has not been decided on - it may not be faster
* GGC algorithm has not been decided on - it may not be faster
</li></ul>
 
<ul><li> JSD1 exact rooting is lurking
* JSD1 exact rooting is lurking
</li></ul>

Revision as of 18:22, 25 January 2013

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, and evilpie Ms2ger
  • Consulted: bhackett billm
  • Informed: Product Marketing

Generational GC - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=619558">Bug 619558</a>

Steps

Exact Rooting done in JS Shell <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=753203">Bug 753203</a> - 12 weeks started

Rooting Analysis on TinderBox (sfink) - 3 weeks

patch is ready for review, would fix the problem with some pushes not getting builds

fix up other stuff broken by above change

patch would fix last remaining problem with getting it on Try server

Unhide it for inbound - keep it green

Get the root analysis build green - two weeks?

Get jit-tests green <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=745742">Bug 745742</a> - 2 days

Get js ref tests green

Get jsapi-tests green <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831376">Bug 831376</a>

Fuzzer coverage of code <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=773746">Bug 773746</a>

rely on static analysis to make this not be a whack-a-mole game

Remove E4X

Do something about JSD

Add exact roots to stack structures - 2 weeks

AddRoot/RemoveRoot for Heap structures - 4 weeks

Static code analysis <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831409">Bug 831409</a>

Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks

Optimize all discovered over-rooting (~100)

Automate static analysis (sfink)

Need a server (dm-sixgill01?)

http://people.mozilla.org/~bhackett/rootingHazards.html

http://people.mozilla.org/~bhackett/gcFunctions.html


JIT Integration with post barriers - 4 weeks, parallelized

IonMonkey <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831506">Bug 831506</a> - 1 week (bhackett)

JaegerMonkey <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764876">Bug 764876</a> - 2 days (bhackett)

Baseline JIT <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831507">Bug 831507</a> - <ask jandem/djvj for an estimate>

Generation 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|.

Exactly Root the Browser <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=831379">Bug 831379</a> - 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)

Test against V8 Earley-Boyer benchmark.

Also v8 deltablue, raytrace

Implement a Nursery <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=706885">Bug 706885</a> - 1 week

We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks

Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable - ??? weeks (start early) (bhackett)

Re-implement HashTable rekeying

We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks

Make the Post Barrier Verifier Green in the browser <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=764882">Bug 764882</a>

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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=765432">Bug 765432</a> - 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