[swift-evolution] What about garbage collection?

[Chris Lattner]

On Feb 8, 2016, at 3:13 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>> Yes, deterministic destruction is a major feature.  Not having to explain what finalizers are (and why they shouldn’t generally be used) is a pretty huge.  Keep in mind that Swift interops with C, so deinit is unavoidable for certain types.
>> 
>> More pointedly, not relying on GC enables Swift to be used in domains that don’t want it - think boot loaders, kernels, real time systems like audio processing, etc.
> 
> I agree that you don't want a GC in these, but on the other hand, from what I know of the current RC implementation, I find it hard to believe that it would be much more acceptable.

Why not?  ARC provides determinism with a “light” runtime, which is all these really need.

> Beyond any cycle efficiency concerns, interrupting a retain/release operation could cause a real carnage, and disabling interrupts while it happens won't necessarily be acceptable either. (Which begs the question: how well does Swift react to signals right now?)

I don’t understand what you mean here.  If you’re talking about unix signals, then it is exactly the same as C: you can only do "async signal safe” operations in a signal handler.  This means you can’t do much of anything.  I don’t see how ARC or GC are related at all to signal handling, since neither would allow you to allocate memory in a signal.

>>> object references cannot be atomically updated
>> 
>> This is true, but Swift currently has no memory model and no concurrency model, so it isn’t clear that this is actually important (e.g. if you have no shared mutable state).
> 
> The fact that references can't be updated atomically will necessarily influence any decision that is taken regarding the concurrency model. The concurrency model pre-proposal <https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst> already uses it 

That isn’t a pre-proposal.  That is a random unendorsed idea, which will not necessarily lead to a specific swift design.

> I will be shocked if the same argument doesn't come up again when these talks actually start.

Sure, but in any case, GC doesn’t solve race conditions or any of the other problems of that come up with that form of concurrency, so claiming that it really moves the needle on concurrency model doesn’t seem particularly useful.

Also, if you take into account the memory model of the hardware, providing atomic pointer updates in a GC setting requires use of synchronizing store instructions that are more expensive than normal stores (at least on most architectures, not including X86).

>>> the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]
>> 
>> I think that this specific point is solvable in others ways, but I’ll interpret this bullet as saying that you don’t want to worry about weak/unowned pointers.  I completely agree that we strive to provide a simple programming model, and I can see how "not having to think about memory management" seems appealing.
> 
> What I actually meant is that a lot of energy is being spent right now on how to address these issues, which wouldn't be issues at all if Swift relied on a garbage collector.

It is hard to read emotion through email so I can’t tell if you intend this to be snarky or not, but I assure you that the effort we are expending on this is a *tiny* fraction of the effort that would be required to successfully switch to GC and make it as good as what we have today.

>> My opinion is yes: while I think it is silly to micromanage memory, I do think thinking about it some is useful. I think that expressing that intention directly in the code adds value in terms of maintenance of the code over time and communication to other people who work on it.
> 
> I don't agree with this. People will very often use `weak` or `unowned` only to break a cycle, not because it really doesn't matter if the object suddenly disappears. The whole weak self capture is a good example of that. The unpopularity of weak references in garbage-collected languages is generally a demonstration that most applications don't need to bother with that.

Sure, I can respect that opinion.  As I said, it was just MHO.

>> I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.
> 
> The way I have to reason about cycles isn't my favorite part of Swift, but I'm not necessarily in favor of having a GC either. I was very surprised that it hadn't come up at all since RC causes actual issues that are currently discussed. (It's also nice that you can ask and have informed people reply to you.)

Makes sense, thank you for providing a list of perceived advantages of GC (allowing a detailed response), instead of just saying “someone else does this, we should too!” :-)

-Chris

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