> Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties.
This last one is great if you want to understand GC tradeoffs btw, highly recommend it.
---
And as the first paper implies, refcounting is often slower (because it trashes caches). The issue is having to propagate the diminution of refcounts amongst a graph of references. This also creates de facto "pauses", much like tracing GC (although arguably more predictable!).
And this "propagation of diminished refcount" is very much a memory traversal — (probably) smaller in scope than (non-incremental) tracing, but also much less local.
e.g. https://users.cecs.anu.edu.au/~steveb/pubs/papers/rc-ismm-20...
> Reference counting and tracing are the two fundamental approaches that have underpinned garbage collection since 1960.
https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
> Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties.
This last one is great if you want to understand GC tradeoffs btw, highly recommend it.
---
And as the first paper implies, refcounting is often slower (because it trashes caches). The issue is having to propagate the diminution of refcounts amongst a graph of references. This also creates de facto "pauses", much like tracing GC (although arguably more predictable!).
And this "propagation of diminished refcount" is very much a memory traversal — (probably) smaller in scope than (non-incremental) tracing, but also much less local.