Comment by adrianm | Hacker News Reader

Comment by adrianm | Hacker News Reader

Parent Full thread

The Garbage Collection Handbook [http://gchandbook.org/] has a good overview of the advantages and disadvantages of reference counting as garbage collection.

In summary,

Advantages:

A. Objects are collected immediately when they become garbage.

B. Programming language runtime support is simpler.

C. Memory can be reclaimed easily in programs with distributed heaps.

Disadvantages:

A. Natural race conditions exist in multi-threaded programs when reference counting is used. Atomic read/writes are necessary when incrementing/decrementing the reference count for an object.

B. Cyclic data structures cannot be reclaimed. (This is why you have to jump through hoops to avoid this in Objective-C and Swift.)

C. Every object in your language which is reference counted needs a field to hold the reference count. Or you need a special object in its stead which "points" to your object, like a shared pointer.

D. Pauses with reference counting are still possible. As stated in the book, "When the last reference to the head of a large pointer structure is deleted, reference counting must recursively delete the descendant of the root."

Two more advantages which are relevant for Swift:

1. Memory high-water-mark is generally lower with RC, which is important for mobile.

2. RC lets you easily determine when there is only one reference to an object. This enables Swift's collections to be value types, one of Swift's key semantics.

> 2. RC lets you easily determine when there is only one reference to an object. This enables Swift's collections to be value types, one of Swift's key semantics.

It also enables some optimisations e.g. Python has immutable strings, but CPython can take advantage of rc=1 to extend strings in-place (avoiding accidentally quadratic concatenation loops until you start storing intermediate references or you try to run the software on alternate implementations)

Another major advantage: No need for "finalizers" which can often run on an unpredictable thread, resurrect objects, etc. There is extensive literature about how problematic finalizers are in practice. deinit in Swift suffers from none of these problems.

There are better alternatives to finalisers for GC'ed languages. Phantom refs in Java are a good example of a finalisation mechanism that explicitly prevents resurrection of objects.

> C. Every object in your language which is reference counted needs a field to hold the reference count. Or you need a special object in its stead which "points" to your object, like a shared pointer.

For a long time (until the 64b class pointers I think) Objective-C used external tables of reference counts instead of embedding refcounts in objects.

The side table only gets a slot for an object when the object is retained (has its reference count incremented) after creation. (Every object starts with a count of 1 at creation.) Before ARC, you could certainly have lots of objects that were never retained after creation. Since ARC tends to be more careful than a human about retaining objects (meaning it retains objects in more places), I don't know how much more load ARC puts on the side table, but I suspect it's not zero.

Regarding D, you can even get stack overflows if the destructors require nested calls.

re ref counting pauses from cascading frees, you can lazily free big data structures by deferring to a later event loop tick or idle event.

Reply on news.ycombinator.com