[swift-evolution] What about garbage collection?

[Taras Zakharko]

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)?

2. For those interested in  mark-and-seep GC, check out the draft of the GC that Mike Pall (author of the incredible LuaJIT tracing compiler) designed: http://wiki.luajit.org/New-Garbage-Collector . I don’t think that GC ever got implemented, but it uses some quite clever tricks to ensure that its incredibly fast. It is also designed around smart use of bit-ops and cache-friendly data structures (e.g. the sweep phases are implemented via streaming  ANDs, ORS and XORS which fully utilise SIMD units). Some very cool stuff. Note: I only link it here because it is interesting, not because I think its a good match for a language like Swift. 

Best, 

 Taras



> On 09 Feb 2016, at 21:24, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In addition to memory and performance, the approach "just write it somehow, and the system will optimize it for you so you don't have to" leads to bad code that is slow and uses too many resources.
> On Tue, Feb 9, 2016 at 1:30 PM David Turnbull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Tue, Feb 9, 2016 at 9:04 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> That island has other inhabitants: video game developers.
> 
> Audio systems too. 60fps video has a hard limit of 16.66ms per frame. Real time audio needs 3ms buffers, imo, but can be less strict depending on the application.
> 
> I think that Swift can become the first serious alternative to C++ for game development and creative coding. For all platforms, not just Avalon (the Isle of Apples, wokka wokka). If Swift becomes a mark-sweep GC language I'm going to get very angry and abandon my work from the last two months: https://github.com/AE9RB/SwiftGL <https://github.com/AE9RB/SwiftGL>
> 
> -david
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160209/a8f006ef/attachment.html>