[swift-evolution] What about garbage collection?

[Vanderlei Martinelli]

-1 for any kind of GC in Swift and any other language/platform.

On Mon, Feb 8, 2016 at 6:26 PM, Goffredo Marocchi via swift-evolution <
swift-evolution at swift.org> wrote:

> Devices being able to house a compact amount of RAM is a device vendor
> concern not a Swift one although the former kind of owns the latter, but
> that is being a bit cheeky I will admit that ;).
>
> Still, iPhone 6 Plus only having 1 GB of RAM... Grrrr... :P. Seriously,
> multitasking suffers greatly on that device as well as having multiple
> opened tabs on Safari...
>
> Sent from my iPhone
>
> On 8 Feb 2016, at 20:11, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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).
>
>
> While true in theory, code that relies on destructors to clean up
> unmanaged resources does not port cleanly to GC as-is in practice. GC of
> course has its own drawbacks. Heap scanning is expensive, thrashing cache
> and burning battery. GCs also require higher memory ceiling proportional to
> the amount of heap actively being used, and GCs suitable for interactive
> use tend to increase responsiveness at the cost of higher memory use, which
> has its own second-order energy costs—devices need more RAM, and spend more
> time swapping or killing, and thus need bigger batteries to refresh all
> that RAM. ARC interoperates better with unmanaged resources, both
> non-memory resources like sockets and files and also C-level memory
> resources. The ARC optimizer and Swift's calling convention also optimize
> toward reclaiming resources closer to their last use, keeping resource
> usage low.
>
> -Joe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20160208/61376517/attachment.html>