Smart pointers instead of GC?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
> 1. RC imposes a time overhead on mutators in order to 
> manipulate the counter.

Usually you just do a retain() when your thread attain ownership 
(at the root of the call tree). If you use embedded counters you 
most likely want the data in the cache anyway, but the cacheline 
is made dirty. So it cost you a write back. That affects reads of 
small objects more than writes.

(The C++ implementation does not use embedded counters.)

> 2. Both the counter manipulation and pointer load/store 
> operations MUST be atomic to prevent races.

Not with transactional memory. You revert to locking, and you 
probably want that kind of synchronization anyway if you run 
multi threaded.

> 3. Naive RC turns read ops into store ops to update the count

If we assume naive RC, then we should assume naive GC.

> 4. No RC can reclaim cyclic data structures, which are much 
> more common than is typically understood. [Bacon and Rajan 2001]

Weak pointers are sufficient to break cycles. You need a model, 
but you should have one anyway.

In cases where you build temporary data structures you can just 
avoid RC altogether and just use a pool, then free the entire 
pool.

> 5. Counter must be the same size as the pointer, which can 
> result in significant overhead for small objects.

No? The counter must be able to hold the # of retain() calls.

> 6. RC can still pause. When the last head to a large pointer 
> structure is deleted, RC MUST delete each descendant node.

Not really, you can postpone the deletion by pushing it onto a 
queue. The free it not by node at your own leisure...

> Note that these are paraphrases of the book, not me talking. 
> And these apply equally to ARC and vanilla RC.

You don't  use RC alone, you use it with fully owned pointers, 
region pools, etc.

GC is simpler and more uniform, and that's it.