Confirmed users
130
edits
JavaScript:GenerationalGC: Difference between revisions
→Initial Steps
Wmccloskey (talk | contribs) |
Wmccloskey (talk | contribs) |
||
| Line 56: | Line 56: | ||
* As a first research step, it would make sense to look into how other collectors work. We should post this information in Bugzilla, as was done for JM. Certainly we should understand pretty deeply how V8's GC works, as well as JSC's. Object Caml has a very fast incremental, generational collector. Sun's G1 collector for Java is considered state-of-the-art, at least for big servers. It is extremely concurrent and parallel. Finally, the Mono collector is supposed to be conservative and copying. It would be good to see what they do. All of these collectors are open source. | * As a first research step, it would make sense to look into how other collectors work. We should post this information in Bugzilla, as was done for JM. Certainly we should understand pretty deeply how V8's GC works, as well as JSC's. Object Caml has a very fast incremental, generational collector. Sun's G1 collector for Java is considered state-of-the-art, at least for big servers. It is extremely concurrent and parallel. Finally, the Mono collector is supposed to be conservative and copying. It would be good to see what they do. All of these collectors are open source. | ||
* We need to get more data to make an informed decision between accurate and conservative scanning. A lot of this is already out there, like the average stack size and number of pointers on the stack. We should also try to measure the time to do a conservative scan in isolation, which we can do by running the scan once without doing any marking, and then doing it again normally. | |||
* Look into the bug databases for V8 and JSC, trying to find cases where their GCs perform badly. These would make good benchmarks for us. | * Look into the bug databases for V8 and JSC, trying to find cases where their GCs perform badly. These would make good benchmarks for us. | ||