On Friday, 7 June 2013, Graydon Hoare wrote: > > Some other things about RC that are less-desirable, that we knew and/or > discovered: > > - It leaks cycles. If you want it to not leak cycles, you need a > cycle collector which has the same properties as above, or a scheme > like you're proposing. I have proposed them in the past. Every > single reviewer I showed a "no cycles" variant of rust to told me > it was unacceptable and they would walk away from a language that > prohibited cycles in all cases. All of them. We tried limiting it > within subsets of the type system rather than pervasively: it still > irritated and confused everyone. > > - It doesn't do anything about fragmentation. Our longer-term plan for > the gc involves moving to mostly-copying[1], which compacts pages > other than the conservatively-scanned set. And is incremental. > > - It actually costs a lot. > > - Code size goes up by a good 30% over tracing GC. Lots of writes > and branches. Lots more icache misses. Many ways of reducing this > are hard to implement, have to happen at the LLVM level, are > patented, or all 3. > > - You can't tell your codegen that pointees are constant anymore, > since you're going to be writing to them. > > - Allocations wind up larger. At least one word extra per. More > if you need to track all the allocations anyways, which you will > want to if you want to be able to free them all on unwind > (rather than rc-- on unwind, which costs much more) and/or if > you want a cycle collector. Current rc boxes cost 4 words extra. > Gc metadata can be stored much more compactly, 1-2 bits per alloc. > > - If you want to support weak pointers, you just added another > dynamic failure mode when the pointee is missing, and slowed > all pointer traversals through that edge.
Another important drawback of RC is that it defeats copy-on-write on fork that at least Linux does. The difference of memory usage between RC and GC can be quite significant in workloads like forking servers.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
