[swift-evolution] What about garbage collection?
fecsedy at gmail.com
Mon Feb 8 15:04:50 CST 2016
In fact, Java is looking to introduce value types and will have to wrestle
with how to do it in a pure GC environment. For Swift a GC is lots of pain
for minimal gain or even a net loss.
On Monday, February 8, 2016, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:
> on Mon Feb 08 2016, Félix Cloutier <swift-evolution at swift.org
> > 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.
> > It seems to me that the two principal upsides of reference counting
> > are that destruction is (essentially) deterministic and performance is
> > more easily predicted. However, it comes with many downsides:
> > object references are expensive to update
> > object references cannot be atomically updated
> > heap fragmentation
> > the closure capture syntax uses up an unreasonable amount of mindshare
> > just because of [weak self]
> > 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).
> > Has a GC been considered at all?
> Yes. Among other problems, you can't do copy-on-write efficiently with
> a GC, because you can't detect a unique reference. And without
> efficient copy-on-write, most interesting value types (Array) are out
> the window.
> swift-evolution mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution