<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 8, 2016 at 12:11 PM, Joe Groff via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div>Has there been a garbage collection thread so far? I understand that reference counting vs. garbage collection can be a heated debate, but it might be relevant to have it.</div><div><br></div><div>It seems to me that the two principal upsides of reference counting are that destruction is (essentially) deterministic and performance is more easily predicted. However, it comes with many downsides:</div><div><br></div><div><ul><li>object references are expensive to update</li><li>object references cannot be atomically updated</li><li>heap fragmentation</li><li>the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]</li></ul></div><div><div><br></div><div>Since Swift doesn&#39;t expose memory management operations outside of `autoreleasepool`, it seems to me that you could just drop in a garbage collector instead of reference counting and it would work (for most purposes).</div></div></div></div></blockquote><br></div></span><div>While true in theory, code that relies on destructors to clean up unmanaged resources does not port cleanly to GC as-is in practice. GC of course has its own drawbacks. Heap scanning is expensive, thrashing cache and burning battery. GCs also require higher memory ceiling proportional to the amount of heap actively being used, and GCs suitable for interactive use tend to increase responsiveness at the cost of higher memory use, which has its own second-order energy costs—devices need more RAM, and spend more time swapping or killing, and thus need bigger batteries to refresh all that RAM. ARC interoperates better with unmanaged resources, both non-memory resources like sockets and files and also C-level memory resources. The ARC optimizer and Swift&#39;s calling convention also optimize toward reclaiming resources closer to their last use, keeping resource usage low.</div><div><br></div><div><br></div></div></blockquote><div><br></div><div>I would imagine that the biggest consideration is compatibility with existing class libraries.  It&#39;s notoriously difficult to integrate libraries with different memory management systems together, whether it be GC + refcounting (Erlang binaries, Java NIO), GC + malloc (JNI, V8 embedding), or refcounting + malloc (Python, ARC/C libraries).  The ownership conventions have to become part of every function &amp; data type that&#39;s exposed across the boundary, and oftentimes you need to copy the whole memory block from one heap to another.  Refcounting seems to integrate with manual memory management a bit more easily than GC does, and of course many existing class libraries already use ARC.</div><div><br></div><div>Also, anyone interested in debating GC vs. refcounting should read this paper, which argues that they are in fact duals and most production systems (generational collectors, train algorithm, cycle detection in refcounts) are hybrids of the two:</div><div><br></div><div><a href="http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf">http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf</a><br></div></div></div></div>