Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions
Jump to navigation
Jump to search
(→Steps) |
(→Steps) |
||
Line 26: | Line 26: | ||
#* Rooting analysis fuzz bugs {{bug|773746}} | #* Rooting analysis fuzz bugs {{bug|773746}} | ||
#** Rely on static analysis to make this not be a whack-a-mole game | #** Rely on static analysis to make this not be a whack-a-mole game | ||
# Remove E4X - done | #* Remove E4X - done | ||
# Do something about JSD | #* Do something about JSD | ||
# Add exact roots to stack structures - 2 weeks | #* Add exact roots to stack structures - 2 weeks | ||
# AddRoot/RemoveRoot for Heap structures - 4 weeks | #* AddRoot/RemoveRoot for Heap structures - 4 weeks | ||
# Static code analysis {{bug|831409}} | #* Static code analysis {{bug|831409}} | ||
# Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks | #** Fix all discovered rooting hazards (~800) (sfink,jonco) - 4 weeks | ||
# Optimize all discovered over-rooting (~100) | #** Optimize all discovered over-rooting (~100) | ||
# Automate static analysis (sfink) | #** Automate static analysis (sfink) | ||
# Need a server (dm-sixgill01?) | #*** Need a server (dm-sixgill01?) | ||
#* http://people.mozilla.org/~bhackett/rootingHazards.html | #*** http://people.mozilla.org/~bhackett/rootingHazards.html | ||
#* http://people.mozilla.org/~bhackett/gcFunctions.html | #*** http://people.mozilla.org/~bhackett/gcFunctions.html | ||
# JIT Integration with post barriers - 4 weeks, parallelized | # JIT Integration with post barriers - 4 weeks, parallelized | ||
#* IonMonkey {{bug|831506}} - 1 week (bhackett) | #* IonMonkey {{bug|831506}} - 1 week (bhackett) | ||
#* JaegerMonkey {{bug|764876}} - 2 days (bhackett) | #* JaegerMonkey {{bug|764876}} - 2 days (bhackett) | ||
#* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate> | #* Baseline JIT {{bug|831507}} - <ask jandem/djvj for an estimate> | ||
# | # Generational Garbage Collection in the Shell | ||
#* Implement prototype algorithm (terrence) - 1 week | #* 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|. | #* 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 | |||
#* Implement a Nursery {{bug|706885}} - 1 week | |||
# Exactly Root the Browser {{bug|831379}} - 10 weeks | # 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. | #* 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. | ||
Line 49: | Line 52: | ||
#* Test against V8 Earley-Boyer benchmark. | #* Test against V8 Earley-Boyer benchmark. | ||
#* Also v8 deltablue, raytrace | #* Also v8 deltablue, raytrace | ||
#* We may need to Implement Bill’s Pools/Zones idea to get the nursery to the requisite perf - 6 weeks | #* 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) | #* 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}} | # Make the Post Barrier Verifier Green in the browser {{bug|764882}} | ||
# Investigate how long it will take to do generational barriers - 1 week | # Investigate how long it will take to do generational barriers - 1 week |
Revision as of 20:57, 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?
- 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 (sfink)
- Need a server (dm-sixgill01?)
- http://people.mozilla.org/~bhackett/rootingHazards.html
- http://people.mozilla.org/~bhackett/gcFunctions.html
- Rooting Analysis on TinderBox (sfink) - done
- 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
- Implement a Nursery bug 706885 - 1 week
- 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)
- 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 - 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