[swift-evolution] What about garbage collection?

[Austin Zheng]

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:
https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html
.

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:
http://docs.elementscompiler.com/Silver/DifferencesAndLimitations/.

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>