[swift-evolution] What about garbage collection?

[David Waite]

> On Feb 9, 2016, at 7:35 AM, Jean-Denis Muys via swift-evolution <swift-evolution at swift.org> wrote:
> 
<snip>
> I find it interesting that the commonly accepted wisdom is that GC is the right thing to do. To quote but one blog post I’ve read:
> 
>> It’s a long since resolved dispute, and GC won. I don’t want Steve Jobs to reach out from the grave and drag us back to the 70s. There’s nothing special about mobile phones: they are more powerful than the computers that GC won on in the first place.

I looked up that article (http://www.lshift.net/blog/2013/09/19/the-great-gc-vs-reference-counting-debate/) and it has several logical fallacies, including the obvious one that reference counting is not a form of GC!

In addition, the point that using a generational GC saves you from having a cost to object allocation is false, that web browsers could not do object compaction because they are written in C/C++ is false (JNI is a perfectly fine, if aged, example of interacting with a compacting GC from C++ code). There is in fact nothing preventing one from doing compaction in a reference counted system which is safe, nor using a reference counted system as part of a javascript implementation (although you would need cycle elimination via tracing as well).

While I didn’t look further, the article is probably correct in terms of the benchmark being complained about but for more meta reasons. It is very difficult to compare GC performance semantics, fundamentally because their designs prioritize different aspects of performance. For instance, mark and sweep GCs generally can fall back to having long pauses as all of memory is checked - which is why modern implementations have generational GCs and concurrent passes to attempt to reduce the frequency of “stop the world” GC pauses (anecdotally, I’ve actually seen a 12 minute stop-the-world GC pause in a production Java 7 application without proper tuning - and some of that tuning was simply setting a lower ceiling of memory usage for the Java process such that when it eventually hit a stop-the-world GC event, it would have less memory to check).

For reference counting, the cost of GC is amortized across usage, meaning you cannot get ‘stop the world’ pauses. Compacting GC systems will require objects to go through write or even read barriers, so such systems don’t operate for ‘free’ at execution time, and likewise still have an effect on things like loop performance. There have been clever attempts to solve the needs of in-code barrier checks using the MMU and page faulting, but also push-back on the trade-offs these have as well. Nobody has ‘won’ the title of ideal garbage collector implementation yet, and I suggest that such concepts as ideal are simply not possible.

> So I’d be interested in understanding why we are about alone on our Apple island with our opinion that RC is better than GC? Are they all collectively wrong in the rest of the universe? (not that I condone argument from majority)

The promise of garbage collection systems in general is that they eliminate the need to think about object lifetime and ownership to produce safe code. With reference counted GC, this is obviously not true in the cases where you can have cycles. With tracing GCs like compacting or mark and sweep, you get closer to achieving this benefit, but with the side effect that a significant source of memory and performance impacts becomes outside of your control.

There is apparently a difference in opinion of whether such a trade-off is worth it ;-)

Objective C had a tracing (but I believe non-compacting) garbage collector for several years; I don’t know if the reasoning behind replacing it with ARC has been published. I can only guess that one of the reasons was the complexity of supporting two GC mechanisms - which, since Swift has to maintain compatibility with reference-counted Objective C code, would be one of the concerns for adding a tracing GC to the language.

-DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/5570c148/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4139 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/5570c148/attachment.p7s>