[swift-evolution] What about garbage collection?

Austin Zheng austinzheng at gmail.com
Wed Feb 10 06:31:37 CST 2016

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:

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

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.)

On Wed, Feb 10, 2016 at 1:08 AM, Craig Cruden via swift-evolution <
swift-evolution at swift.org> wrote:

> >
> > - 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?
> 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.).
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/4e41f282/attachment.html>

More information about the swift-evolution mailing list