A long time ago (2010), a post was made to the rust-lang mailing list on the topic of immutable data structures and reference counting. In particular, the author points out that naïve reference counting is quite expensive in a multi-core setup (due to the large number of cache invalidations), and that there are many known techniques for significantly reducing this cost:
The cost of reference counting in a multi-core scenario is a concern. Rust already limits the number of reference operations using aliases, which presumably gets rid of a lot of the cost. Is Rust wedded to the idea of having accrate refcounts at all times? As far as I can tell, modern ref-counting algorithms seem to be about on par with modern GC algorithms for performance (just barely) even in the context of multithreading, but they achieve this feat through deferred ref-counting and things like that. Should Rust not do that instead? I kind of think refcounts may be the way forward in the future, because the cost of GC’ing in a ref-count system is proportional to the amount of actual garbage, rather than being proportional to the size of the heap, but it seems like the consensus on this issue in the literature is that refcounts are only performant when they’re not being constantly kept up to date. Am I wrong?
Has any consideration been given to whether Rust should incorporate some more clever strategies for reference counting? I searched both RFCs and issues, but couldn’t find any reference to it? This is of particular important to read-mostly data structures in which readers are constantly accessing objects, but where those objects are occasionally modified or deleted. If readers are required to always modify the global refcount atomically, this kills multi-core scalability as the cache coherency traffic becomes the bottleneck.