<div dir="ltr">Mark-and-sweep GC seems to be a non-starter as long as Swift's collections remain copy-on-write value types. The way an Array (or other dynamically sized stdlib collection) knows to write to its existing buffer, rather than creating a whole new copy, is by looking at the buffer object's reference count (via the `isUniquelyReferenced` API). Mike Ash has a good summary of how this process works here: <a href="https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html">https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html</a>.<div><br></div><div>The RemObjects Silver Swift-alike compiler, which targets the JVM and CLR, is forced to treat its collections as reference types because of how COW is implemented: <a href="http://docs.elementscompiler.com/Silver/DifferencesAndLimitations/">http://docs.elementscompiler.com/Silver/DifferencesAndLimitations/</a>.</div><div><br></div><div>The most pertinent questions with regards to Swift GC are: whether or not some acceptably efficient form of efficient copy-on-write mechanism for value type collections in a tracing GC environment exists, and if not whether the enormous semantic change that turning collections into reference types would entail would be worthwhile. (This in turn would have a whole set of knock-on effects; for example, generic stdlib collections could no longer be properly covariant.)</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 1:08 AM, Craig Cruden via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> - arguments regarding energy efficiency, memory efficiency, or more generally hardware limitations seem to me rather short-sighted, as in “640 KB or RAM should be enough for all times to come” (original design decision by IBM for the PC). Is Swift a language designed for todays hardware? Or is it supposed to outlast it a wee bit?<br>
<br>
</span>For the foreseeable future - energy efficiency is a very real and important factor. Battery technology (as compared to other technology) is not moving quickly, so being efficient is important. (and one of the items that is listed as a plus for iDevices over the competion) The focus of the language (even though open sourced) is primarily focused on a programming language for “desktop” and iDevices. A majority of the computers sold by Apple rely on battery (laptops, iDevices, etc.).<br>
<br>
The java type GC has a big advantage is that incompetent programmers don’t have to worry about memory management (and they make up a majority of programmers). And yes, I have seen cases where someone wrote a server (microsoft based) component that had so many cylindrical references that people assumed would just clean up — that to make it work they had to write another monitor application to watch for the application memory usage growing above a certain size based on memory leaks then force a “reboot” of it :p<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>