On 17 Sep 2008, at 13:46, Quentin Mathé wrote: > ok. Do you imply that the algorithm detailed in this paper is more > tracing-inspired than the one in GCKit though? I mean, if you consider > that the cycle detection in GCKit simulates tracing by scanning the > refcounts inside the cycle.
Tracing and cycle detection with reference counting are both degenerate cases of the same general algorithm (see the Unified Theory paper by the same guys - probably the only paper on GC I would make recommended reading for everyone thinking about programming). The approach described in this paper is likely to be slightly faster than the current approach. It has two disadvantages: 1) It's concurrent, meaning that existing threads will be preempted to run the GC when the number of threads is greater than the number of processor cores. 2) It's concurrent, meaning that any implementation is likely to be buggy, difficult to test, and almost impossible to prove correct. Finding bugs in the sequential version was hard enough... If (when we actually start using GCKit for anything) it is problematic in terms of performance then I'll consider implementing the concurrent version, but until then it doesn't seem worth it. I have not done any serious benchmarks with CGKit, however it's worth noting that the scanner will only be run on an object when: - It is released but not dealloc'd and - It still exists when the current autorelease pool is destroyed. This means that it is only likely to be run on a very small subset of all objects. Making it concurrent is likely to cost more from the extra context switches than it saves. I will, however, add a hardware implementation to my feature wish-list for my next CPU ;-) David _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
