Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 17: Line 17:
== Steps ==
== Steps ==


# Exact Rooting done in JS Shell {{bug|753203}} - 12 weeks started
=== 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
* Rooting Analysis on TinderBox (sfink) - done
#* Get the root analysis build green - two weeks?
** Still need to unhide it for inbound - get it green, keep it green
#** Get jit-tests green {{bug|745742}}
* Get the root analysis build green - two weeks?
#** Get js ref tests green  
** Get jit-tests green {{bug|745742}}
#** Get jsapi-tests green {{bug|831376}}
** Get js ref tests green  
#* Rooting analysis fuzz bugs {{bug|773746}}
** Get jsapi-tests green {{bug|831376}}
#** Rely on static analysis to make this not be a whack-a-mole game
* Rooting analysis fuzz bugs {{bug|773746}}
#* Remove E4X - done
** Rely on static analysis to make this not be a whack-a-mole game
#* Do something about JSD
* Remove E4X - done
#* Add exact roots to stack structures - 2 weeks
* Do something about JSD
#* AddRoot/RemoveRoot for Heap structures - 4 weeks
* Add exact roots to stack structures - 2 weeks
#* Static code analysis {{bug|831409}}
* AddRoot/RemoveRoot for Heap structures - 4 weeks
#** Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
* Static code analysis {{bug|831409}}
#** Optimize all discovered over-rooting (~100)
** Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
#** Automate static analysis {{bug|834912}} (sfink)
** Optimize all discovered over-rooting (~100)
#*** Need a server (dm-sixgill01?)
** Automate static analysis {{bug|834912}} (sfink)
#*** http://people.mozilla.org/~sfink/rootingHazards.txt
*** Need a server (dm-sixgill01?)
#*** http://people.mozilla.org/~bhackett/gcFunctions.html
*** http://people.mozilla.org/~sfink/rootingHazards.txt
# JIT Integration with post barriers - 4 weeks, parallelized
*** http://people.mozilla.org/~bhackett/gcFunctions.html
#* IonMonkey {{bug|831506}} - 1 week (bhackett)
 
#* JaegerMonkey {{bug|764876}} - 2 days (bhackett)
=== JIT Integration with post barriers - 4 weeks, parallelized ===
#* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate>
 
# Generational Garbage Collection in the Shell
* IonMonkey {{bug|831506}} - 1 week (bhackett)
#* Implement prototype algorithm (terrence) - 1 week
* JaegerMonkey {{bug|764876}} - 2 days (bhackett)
#* This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate>
#* Re-implement HashTable rekeying
 
#** We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
=== Generational Garbage Collection in the Shell ===
#** at least part of this is {{bug|726687}}
 
# Exactly Root the Browser {{bug|831379}} - 10 weeks
* Implement prototype algorithm (terrence) - 1 week
#* 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.
* This is a potential milestone: we would need to build it and test it on TBPL similar to how |r| works now -- |GGCJS|.
# Performance Tuning - 4 weeks (This should probably start asap)
* Re-implement HashTable rekeying
#* Implement a Nursery {{bug|706885}} - 1 week
** We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
#* Test against V8 Earley-Boyer benchmark.
** at least part of this is {{bug|726687}}
#** 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
=== Exactly Root the Browser {{bug|831379}} - 10 weeks ===
#* Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable - ??? weeks (start early) (bhackett)
 
# Make the Post Barrier Verifier Green in the browser {{bug|764882}}
* 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.
#* 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.  
=== Performance Tuning - 4 weeks (This should probably start asap) ===
#* Make JS_IsAboutToBeFinalized indirect {{bug|765432}} - 10 weeks
 
* 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 - ??? weeks (start early) (bhackett)
 
=== 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 ==
== Other ==

Revision as of 21:11, 5 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, and evilpie Ms2ger
  • Consulted: bhackett billm
  • Informed: Product Marketing

Generational GC - bug 619558

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?
  • 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

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 - ??? weeks (start early) (bhackett)

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