Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

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 js ref tests green  

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

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

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

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)

Re-implement HashTable rekeying

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

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.  

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.