[swift-evolution] What about garbage collection?

Tue Feb 9 10:35:42 CST 2016

I sympathize. I said less of an issue. Still a problem for large applications, but when done correctly, a GC pause won’t occur in the middle of a request being processed, so the user won’t suffer from this directly.

Swift’s primary application are interactive apps, where we ideally want 60fps all the time. So there’s only milliseconds for any garbage collection randomly happening.

— Radek

> On 09 Feb 2016, at 16:32, Ondrej Barina <obarina at gmail.com> wrote:
> 
> -1
> GC does not have performance problems on server side??
> Please tell that to my colleges who are spending 50% of their time
> analysing and tweaking GC in java after every release of new versions.
> It becoming such a pain sometimes, that we are discussing re-writing
> some servers from Java to C++ (just to avoid GC issues)
> Ondrej B.
> 
> On Tue, Feb 9, 2016 at 3:40 PM, Radosław Pietruszewski
> <swift-evolution at swift.org> wrote:
>> An***id lagged behind iOS for years in smoothness and responsiveness at
>> comparable hardware — my understanding is that this is largely because of GC
>> pauses.
>> 
>> I love GC. I’d love GC in Swift, too. But it really is a real performance
>> problem in _interactive_ applications (much less of an issue for server side
>> stuff), on memory-constrained devices.
>> 
>> — Radek
>> 
>> On 09 Feb 2016, at 15:35, Jean-Denis Muys via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> My understanding (from what I’ve seen in the literature, but I am in no way
>> an expert) is that RC has worse worse case behaviour than GC regarding
>> pauses.
>> 
>> Also arguments regarding RAM use (and perhaps even battery use), as all
>> hardware resource-based arguments, have always been proven wrong in the past
>> as hardware has evolved to more and better.
>> 
>> The usual argument is RAM is cheap, programmer’s time, especially debugging
>> time, is expensive.
>> 
>> I find it interesting that the commonly accepted wisdom is that GC is the
>> right thing to do. To quote but one blog post I’ve read:
>> 
>> It’s a long since resolved dispute, and GC won. I don’t want Steve Jobs to
>> reach out from the grave and drag us back to the 70s. There’s nothing
>> special about mobile phones: they are more powerful than the computers that
>> GC won on in the first place.
>> 
>> 
>> So I’d be interested in understanding why we are about alone on our Apple
>> island with our opinion that RC is better than GC? Are they all collectively
>> wrong in the rest of the universe? (not that I condone argument from
>> majority)
>> 
>> I can only state that my experience with GC has been with mostly with
>> Macintosh Common Lisp a rather long time ago, and I did really love it.
>> 
>> So for me, GC would be a +1, but not a very strong one, as I find RC
>> adequate.
>> 
>> Jean-Denis
>> 
>> 
>> 
>> On 09 Feb 2016, at 07:01, Colin Cornaby via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> I thought I’d add my opinion to this thread even though it’s been well
>> covered in different posts, just to put more weight on the -1 argument…
>> 
>> I spend most my time dealing with performance sensitive code, and Swift’s
>> predictability is a very strong pro for it against languages like Java.
>> Java’s garbage collector provides too much uncertainty and instability to
>> performance.
>> 
>> There certainly are tradeoffs. ARC won’t catch things like circular retain
>> loops. But as mentioned, tagged pointers on the modern architecture take
>> care of the retain/release overhead.
>> 
>> I’ll put it a different way that sums up why I felt the need to reply: ARC
>> has it’s inconveniences, but moving to garbage collection would likely lead
>> us to abandon any plans to adopt Swift for many of our performance sensitive
>> projects. If someone solves the “pausing” problem in a garbage collected
>> language I’d reconsider. But until then it would take Swift out of
>> consideration for a lot of projects.
>> 
>> 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).
>> 
>> Has a GC been considered at all?
>> 
>> Félix
>> 
>> _______________________________________________
>> 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
>> 
>> 
>> _______________________________________________
>> 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
>> 