<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In the non trivial systems I have worked on which require loading complex object graphs or parts thereof from a database I have to think about cyclic references and ownership as well to allow loading parts of object graphs (for performance and memory reasons and we are talking about a server with lots of RAM here) without accidentally loading the whole graph. That’s quite the same problem and an important design aspect of the domain model IMO.<div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 10.02.2016 um 08:50 schrieb Goffredo Marocchi &lt;<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>&gt;:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">It does break the make it easy to debug rule though. In any non trivial system worked on by a moderate to large team, manually hunting cyclic references and appropriately breaking them down without introducing bugs can still be very painful. GC is one of those technologies where you trade the efficiency you mention for a safer and easier to use memory model where you would spend a lot less time to debug for correctness.</div><div class=""><br class=""></div><div class="">There are some system where memory safety, type safety, and thread safety rule over pure performance concerns... Reasons why C# and Java still have this much traction. Just as much as the small tax of reference counting (and having so much accumulated knowledge that is able to exploit the vast ways it allows you to go about it) is still greater than not 0... see why C++ still has this enormous presence on all platforms where performance really matters... Games on iOS too.</div><div class=""><br class=""></div><div class="">Still, if GC never comes to Swift, say not even a cycle detector exclusively say in Debug builds on the iOS Simulator just to restrict things a bit (Address Sanitiser does make a precedence), &nbsp;but spotting them and hunting them down using Xcode becomes easier then it is a much much better overall win.<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 10 Feb 2016, at 06:14, Thorsten Seitz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""></div><div class="">Strong -1 for GC.</div><div class=""><br class=""></div><div class="">I think the advantages of ARC over GC as given by Chris, Joe and Dave with regards to energy efficiency, memory efficiency, caching behavior, predictability, value types with copy on write and declarative memory management on the object graph level are essential and indispensable.&nbsp;</div><div class=""><br class=""></div><div class="">And yes, I see it as an advantage having to think about memory management dependencies on the object graph level and deciding how to break cycles. I think this leads to much cleaner object models.</div><div class=""><br class=""></div><div class="">-Thorsten&nbsp;</div><div class=""><br class="">Am 08.02.2016 um 22:00 schrieb Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">Technically speaking, reference counting is a form of garbage collection, but I get what you mean. &nbsp;Since there are multiple forms of GC, I'll assume that you mean a generational mark and sweep algorithm like you’d see in a Java implementation.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">It seems to me that the two principal upsides of reference counting are that destruction is (essentially) deterministic and performance is more easily predicted.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, deterministic destruction is a major feature. &nbsp;Not having to explain what finalizers are (and why they shouldn’t generally be used) is a pretty huge. &nbsp;Keep in mind that Swift interops with C, so deinit is unavoidable for certain types.</div><div class=""><br class=""></div><div class="">More pointedly, not relying on GC enables Swift to be used in domains that don’t want it - think boot loaders, kernels, real time systems like audio processing, etc.</div><div class=""><br class=""></div><div class="">We have discussed in the passed using hybrid approaches like introducing a cycle collector, which runs less frequently than a GC would. &nbsp;The problem with this is that if you introduce a cycle collector, code will start depending on it. In time you end up with some libraries/packages that works without GC, and others that leak without it (the D community has relevant experience here). &nbsp;As such, we have come to think that adding a cycle collector would be bad for the Swift community in the large.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> However, it comes with many downsides:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">object references are expensive to update</li></ul></div></div></div></blockquote><div class=""><br class=""></div><div class="">Most garbage collectors have write barriers, which execute extra code when references are updated. &nbsp;Most garbage collectors also have safe points, which means that extra instructions get inserted into loops.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><li class="">object references cannot be atomically updated</li></ul></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is true, but Swift currently has no memory model and no concurrency model, so it isn’t clear that this is actually important (e.g. if you have no shared mutable state).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><li class="">heap fragmentation</li></ul></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is at best a tradeoff depending on what problem you’re trying to solve (e.g. better cache locality or smaller max RSS of the process). &nbsp;One thing that I don’t think is debatable is that the heap compaction behavior of a GC (which is what provides the heap fragmentation win) is incredibly hostile for cache (because it cycles the entire memory space of the process) and performance predictability.</div><div class=""><br class=""></div><div class="">Given that GC’s use a lot more memory than ARC systems do, it isn’t clear what you mean by GC’s winning on heap fragmentation.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><li class="">the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]</li></ul></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think that this specific point is solvable in others ways, but I’ll interpret this bullet as saying that you don’t want to worry about weak/unowned pointers. &nbsp;I completely agree that we strive to provide a simple programming model, and I can see how "not having to think about memory management" seems appealing.</div><div class=""><br class=""></div><div class="">On the other hand, there are major advantages to the Swift model. &nbsp;Unlike MRR, Swift doesn’t require you to micromanage memory: you think about it at the object graph level when you’re building out your types. &nbsp;Compared to MRR, ARC has moved memory management from being imperative to being declarative. &nbsp;Swift also puts an emphasis on value types, so certain problems that you’d see in languages like Java are reduced.</div><div class=""><br class=""></div><div class="">That said, it is clear that it takes time and thought to use weak/unowned pointers correctly, so the question really becomes: does reasoning about your memory at the object graph level and expressing things in a declarative way contribute positively to your code? &nbsp;</div><div class=""><br class=""></div><div class="">My opinion is yes: while I think it is silly to micromanage memory, I do think thinking about it some is useful. I think that expressing that intention directly in the code adds value in terms of maintenance of the code over time and communication to other people who work on it.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Since Swift doesn'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 class=""><br class=""></div><div class="">Has a GC been considered at all?</div></div></div></div></blockquote><br class=""></div><div class="">GC also has several *huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted *much* more memory than the process is actually using. &nbsp;Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. &nbsp;Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life).</div><div class=""><br class=""></div><div class="">I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.</div><div class=""><br class=""></div><div class="">-Chris</div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>