I would consider building a reference counting GC in a language with mixed high level and low level pointers. It's difficult to use a tracing GC when you can have pointers targeting the middle of an object (How to find which object is pointed to efficiently? Go supports a tracing GC with such pointers though with memory management heavy hacks). In Smalltalk all pointers to objects at GC time are to the base header (aside from IP, but that's not a problem), so there's no real point in using reference counting IMO. For C++, smart pointers and reference counting might be relevant. A tracing GC might be faster in C++, but for sure it's going to be hell to implement. There's performance and there's complexity. The blog post does not talk about that, though he says that since Apple has more skills in reference counting it makes sense for them to use it.

Richard Jones said at the VM summer school that he did not like reference counting GC since it was hard to make it efficient in a multi threaded environment. Just pointing that out.

Whatever. Reference counting vs tracing GC is an old time conflict and people will argue about it for the next century, if not more. And don't talk to me about inline caches versus virtual tables, a paper a few years ago showed that v-tables are faster and now so many people are trying to convince me to implement that for our VM. Even if it is faster, and I am not saying it is, rewriting the runtime to use v-table over inline caches requires a crazy amount of engineering time and complexity. 

On Thu, Apr 26, 2018 at 5:09 PM, Eliot Miranda <> wrote:
Hi Clément, Hi All,

   I answered a question on Quora on GC recently and that same question was answered by Jon Harrop, who has taken a good look at GC performance.  If you're not on Quora yet, let me encourage you.  This blog post is a good read:

And in Jon's answer to the Quora question he mentions Staccato, A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors

That's my reading for today.

_,,,^..^,,,_ (phone)