On Tue, May 1, 2012 at 4:07 AM, Matthieu Monrocq <[email protected]> wrote: > As a consequence, I am unsure of the impact this article should have on > Rust's GC design. The implementation strategies presented are very clear and > the advantages/drawbacks clearly outlined, which is great (big thank you to > the OP); however the benchmarks and conclusions might be a tad Java-centric > and not really apply to Rust's more advanced type system. >
My conjecture is that Java is *especially* unsuitable for RC for the following reasons: * lots of references, thus lots of reference traffic, thus lots of ref count inc/dec. * lots of garbage, thus more expensive for an algorithm for which the cost is proportional to the amount of garbage (RC) rather than to the amount of heap (GC). So I'd expect vanilla RC to do better in comparison to GC (though perhaps not beat it) in Rust than in Java. Applying the optimizations mentioned in the article (most of which rely on using deferred ref counting, which does mean you give up on predictable timing for deallocations) may make RC significantly better in Rust. Seb > --- > > Finally I think it might be worth considering having two distinct GC > strategies: > - one for immutable objects (that only references other immutable objects) > - one for the rest (mutable objects with potential cycles) > > I see no reason to try and employ the same strategy for such widely > different profiles other than the potential saving in term of coding effort. > But then trying to cram every single usecase in a "generic" algorithm while > keeping it efficient seems quite difficult too, whereas having several > specialized mechanisms might make for much clearer code. > > One idea I have toyed with for my own was to have simple stubs: design a > clear API for GC, with two (or more) sets of functions for example here, and > call those functions instead of inlining their effect (in the IR). By > providing the functions definitions externally (but inlining them in each IR > module) this makes it easy to switch back and forth between various > implementations whilst still retaining the efficiency of the LLVM backend to > inline/optimize the calls. > > This means one can actually *test* the strategies, and perhaps even let the > user *choose* which one better suits her needs. Of course coherency at the > executable level might be necessary. > > -- Matthieu -- Sebastian Sylvan _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
