Javascript:SpiderMonkey:ProjectGenerationGarbageCollection: Difference between revisions

Javascript:SpiderMonkey:ProjectGenerationGarbageCollection (view source)

Revision as of 20:31, 5 February 2013

22 bytes added , 5 February 2013

m

→‎Other

Sfink

Confirmed users

328

edits

@@ Line 61: / Line 61: @@
 == Other ==
-Should we establish a new  benchmark specifically for GGC. (sfink votes yes)
+* 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.
-What would it measure? there are multiple goals, e.g. throughput/MMU/pause time
+* 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
-Should we make it a public benchmark?
+* 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.
-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 ==