On Tue, May 1, 2012 at 5:51 PM, Sebastian Sylvan <sebastian.syl...@gmail.com > wrote:
> On Tue, May 1, 2012 at 4:07 AM, Matthieu Monrocq > <matthieu.monr...@gmail.com> 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 > > I agree that the technics outlined, especially with the details on their advantages/drawbacks are a very interesting read. As for the predictable timing, anyway it seems hard to have something predictable when you take cycle of references into account: I do not know any inexpensive algorithm to realize that by removing a link you are suddenly creating a self-sustaining group of objects that should be collected. Therefore I would venture that anyway such groups would be collected in a deferred fashion (using some tracing algorithm). -- Matthieu > > --- > > > > 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 Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
