Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(→‎Steps: Reformatted. Kind of dense, but totally updatable now)
Line 17: Line 17:
== Steps ==
== Steps ==


#Exact Rooting done in JS Shell [https://bugzilla.mozilla.org/show_bug.cgi?id=753203 Bug 753203] - 12 weeks started
# Exact Rooting done in JS Shell {{bug|753203}} - 12 weeks started
##Rooting Analysis on TinderBox (sfink) - 3 weeks
#* Rooting Analysis on TinderBox (sfink) - done
###Patch is ready for review, would fix the problem with some pushes not getting builds
#** Still need to unhide it for inbound - get it green, keep it green
###Fix up other stuff broken by above change
#* Get the root analysis build green - two weeks?
###Patch would fix last remaining problem with getting it on Try server
#** Get jit-tests green {{bug|745742}}
###Unhide it for inbound - keep it green
#** Get js ref tests green  
##Get the root analysis build green - two weeks?
#** Get jsapi-tests green {{bug|831376}}
###Get jit-tests green [https://bugzilla.mozilla.org/show_bug.cgi?id=745742 Bug 745742] - 2 days
#* {{bug|773746}}
###Get js ref tests green  
#** Rely on static analysis to make this not be a whack-a-mole game
###Get jsapi-tests green [https://bugzilla.mozilla.org/show_bug.cgi?id=831376 Bug 831376]
# Remove E4X - done
##Fuzzer coverage of code [https://bugzilla.mozilla.org/show_bug.cgi?id=773746 Bug 773746]
# Do something about JSD
###Rely on static analysis to make this not be a whack-a-mole game
# Add exact roots to stack structures - 2 weeks
 
# AddRoot/RemoveRoot for Heap structures - 4 weeks
 
# Static code analysis {{bug|831409}}
Exact Rooting done in JS Shell [https://bugzilla.mozilla.org/show_bug.cgi?id=753203 Bug 753203] - 12 weeks started
# Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
 
# Optimize all discovered over-rooting (~100)
Rooting Analysis on TinderBox (sfink) - 3 weeks
# Automate static analysis (sfink)
 
# Need a server (dm-sixgill01?)
patch is ready for review, would fix the problem with some pushes not getting builds
#* http://people.mozilla.org/~bhackett/rootingHazards.html
 
#* http://people.mozilla.org/~bhackett/gcFunctions.html
fix up other stuff broken by above change
# JIT Integration with post barriers - 4 weeks, parallelized
 
#* IonMonkey {{bug|831506}} - 1 week (bhackett)
patch would fix last remaining problem with getting it on Try server
#* JaegerMonkey {{bug|764876}} - 2 days (bhackett)
 
#* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate>
Unhide it for inbound - keep it green
# Generation Garbage Collection in the Shell
 
#* Implement prototype algorithm (terrence) - 1 week
Get the root analysis build green - two weeks?
#* 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 {{bug|831379}} - 10 weeks
Get jit-tests green [https://bugzilla.mozilla.org/show_bug.cgi?id=745742 Bug 745742] - 2 days
#* 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)
Get js ref tests green
#* Test against V8 Earley-Boyer benchmark.
 
#* Also v8 deltablue, raytrace
Get jsapi-tests green [https://bugzilla.mozilla.org/show_bug.cgi?id=831376 Bug 831376]
# Implement a Nursery {{bug|706885}} - 1 week
 
#* We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks
Fuzzer coverage of code [https://bugzilla.mozilla.org/show_bug.cgi?id=773746 Bug 773746]
# Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable - ??? weeks (start early) (bhackett)
 
# Re-implement HashTable rekeying
rely on static analysis to make this not be a whack-a-mole game
#* 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 {{bug|764882}}
Remove E4X  
# 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.  
Do something about JSD
# Make JS_IsAboutToBeFinalized indirect {{bug|765432}} - 10 weeks
 
Add exact roots to stack structures - 2 weeks
 
AddRoot/RemoveRoot for Heap structures - 4 weeks
 
Static code analysis [https://bugzilla.mozilla.org/show_bug.cgi?id=831409 Bug 831409]
 
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 [https://bugzilla.mozilla.org/show_bug.cgi?id=831506 Bug 831506] - 1 week (bhackett)
 
JaegerMonkey [https://bugzilla.mozilla.org/show_bug.cgi?id=764876 Bug 764876] - 2 days (bhackett)
 
Baseline JIT [https://bugzilla.mozilla.org/show_bug.cgi?id=831507 Bug 831507] - <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 [https://bugzilla.mozilla.org/show_bug.cgi?id=831379 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)
 
Test against V8 Earley-Boyer benchmark.
 
Also v8 deltablue, raytrace
 
Implement a Nursery [https://bugzilla.mozilla.org/show_bug.cgi?id=706885 Bug 706885] - 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=764882 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=765432 Bug 765432] - 10 weeks


== Other ==
== Other ==

Revision as of 20:28, 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 - [https://bugzilla.mozilla.org/show_bug.cgi?id=619558 Bug 619558

Steps

  1. 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?
    • bug 773746
      • Rely on static analysis to make this not be a whack-a-mole game
  2. Remove E4X - done
  3. Do something about JSD
  4. Add exact roots to stack structures - 2 weeks
  5. AddRoot/RemoveRoot for Heap structures - 4 weeks
  6. Static code analysis bug 831409
  7. Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks
  8. Optimize all discovered over-rooting (~100)
  9. Automate static analysis (sfink)
  10. Need a server (dm-sixgill01?)
  11. JIT Integration with post barriers - 4 weeks, parallelized
  12. 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|.
  13. 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.
  14. Performance Tuning - 4 weeks (This should probably start asap)
    • Test against V8 Earley-Boyer benchmark.
    • Also v8 deltablue, raytrace
  15. Implement a Nursery bug 706885 - 1 week
    • We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks
  16. Refactor code to avoid rooting on hot paths and keep rooter overhead acceptable - ??? weeks (start early) (bhackett)
  17. Re-implement HashTable rekeying
    • We undid this code because it was a perf regression and was still a bit buggy. (terrence) - 3 weeks
  18. Make the Post Barrier Verifier Green in the browser bug 764882
  19. 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.
  20. 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=513214"