[swift-evolution] What about garbage collection?

[Andrew Trick]

> On Feb 9, 2016, at 1:28 PM, Taras Zakharko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I am also agains introducing mark-and-sweep GC to Swift. I don’t see any real advantages to having it in the language and while explicitly building ownership graphs might seem tedious, I think it is a very useful  modelling step that allows one to build better code. 
> 
> But since we are already talking about this, here are two small thoughts:
> 
>  1. I would love to see support for region-based allocation in Swift. To those unfamiliar with the concept: a region is basically a sub-heap from which objects are allocated. The allocation is very fast, because it usually just increments the pointer (a region could be implemented as a linked list of memory pages). All objects in the region are deallocated at once. This can be very useful in a case where you have a lot of small allocations that are guaranteed not to escape a certain scope. Essentially, you can remove the overhead of refcounting (but ARC should take care of that already), but also remove the overhead of deallocating every small object individually. It should be possible to do this in a safe way, e.g. by ensuring that only one reference to a object exists of any time (my type theory is very very rusty, but wasn’t that accomplished by linear types)?

Good point. There are actually two ARC performance problems that eventually need to be solved for some problem domains vis-à-vis GC implementations:

1. Allocation and deallocation overhead.

2. Concurrency. Cache efficiency is more nuanced than this thread makes it seem. We should admit that standard reference counts are a bad idea for shared objects and rest assured that Swift’s concurrency model will take that into consideration.

I’m excited and optimistic about solving these, but neither are going to be solved in Swift 3, and we don’t have the bandwidth now to debate proposals.

Andy