----- Original Message -----
Not to derail this further with a defense of the CC, but... > CC is still a performance and memory and safety problem. At this point, I think the GC is a bigger performance problem. ;) Ok, so it is doing much more stuff than the CC... > Yeah, I shouldn't have mentioned safety there, since the fundamental > problem is the same whether or not you use CC or GC. You still have to > teach the JS engine or the CC about the object graph. Yeah, automatic memory management of C++ is just a pain. The CC is a little nicer because mistakes are (often) only leaks, not arbitrary code execution, like they are with GC. Oilpan seems to be dealing with this problem by using static analysis to check the correctness of their trace methods. I investigated something like that for the CC using Dehydra, but there are a lot of weird traverse methods out there. > We use compiler support for this in Rust, thankfully, eliminating the > safety and annoyance-of-writing-trace-hooks problems (via abuse of the > serialization module--this should eventually migrate to something better). > > I guess depending on whether you include leaks as part of safety, you > have to be careful to make sure your ForgetSkippable optimizations to > throw things out of the purple buffer are correct. Leaks should not be put in the same category as arbitrary code execution, because adversaries are not going to exploit obscure engine bugs to cause leaks. You only need to worry about what people hit in practice. In about 2.5 years of ForgetSkippable optimizations, we've only had a handful of bugs. I was certainly worried about things being removed from the graph that shouldn't have been, but it isn't really a problem in practice. Anyways, I think the main ugliness of the cycle collector is in the integration with the garbage collected heap, and all of the unmark gray stuff. If you can get the perf and implementation costs you need with just one collector, then great. (I think the latter is an overlooked benefit of the CC for Gecko, in that we can mostly just ignore it and it does its thing.) > I understand that they're necessary, but the purist in me really dislikes > wiring > application-specific logic into the garbage collector :) The collector itself just runs per-class callbacks for forget skippable, so I think it isn't too bad all told. The reality is that if you really care about perf, and you are using your collector for a specific program you also control and care about, you are going to need to take advantage of whatever information you can. For instance, the JS allocator is effectively aware of which tab each object is in, so that it can put them in the same zone, because things in the same tab will likely have similar lifetimes. Andrew > > Patrick > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
