[swift-evolution] What about garbage collection?

[Janosch Hildebrand]

> On 08 Feb 2016, at 21:39, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I should check because it's been a while, but in Objective-C loops that quickly modified references, I've measured objc_retain make up to 15% of the loop's cost.

In my experience it is definitely possible to run into such situations with Swift, however while a GC might solve that particular issue you'll just get a different crop of issues from a GC.

Also, the compiler has already made huge strides in this area in my experience, doubly so if you use whole module optimization. I don't think this is a big issue for most people and applications.

And ARC has the advantage that this can be identified (by profiling) and worked around pretty well using tools such as:

* inout
* unsafe(unowned)
* UnsafePointer
* Unmanaged/UnsafeReference

depending on the circumstances. It's not trivial and there might be a bit of a learning curve but ultimately it's very predictable and abstractable. Working around GC issues seems a lot trickier to me.

I also think that for example Rusts 'borrowed references' would be a big help in this area – and those have been discussed on this list previously with the Swift team mentioning that they would be interested to explore this direction.

- Janosch

> My understanding is that most of that cost comes from tracking references in a global hash map, which I can't imagine being particularly kind to memory use or cache performance either.
> 
>> Le 8 févr. 2016 à 15:11:52, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> a écrit :
>> 
>>> 
>>> On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto: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


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