[swift-evolution] What about garbage collection?

[Joe Groff]

> On Feb 10, 2016, at 4:31 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <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/ <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.)

It's within the realm of possibility to have a hybrid approach, where value type buffers have reference counts maintained by compiler-inserted retain/release operations when semantic copies occur in an otherwise GC environment.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/a9c00bca/attachment.html>