[swift-evolution] What about garbage collection?

[Paul Cantrell]

Since GC is getting a lot of hate on this thread, I’ll throw it a little love — though ultimately I agree that it’s probably not right for Swift.

There’s no denying that GC eases programmer burden. Having to explicitly break every cycle takes effort, and sometimes undermines abstraction. There’s a tradeoff here: more deterministic / consistent performance in exchange for developer time. ARC keeps that effort pretty low, but it’s nonzero.

As Jean-Denis noted:

> On Feb 9, 2016, at 8:35 AM, Jean-Denis Muys via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

…GC has indeed pretty much won on the server side. That makes sense, because — at least as I understand it — the downsides of GC are much less severe there:

Quadrupling physical RAM is far less of a concern on a server than it is on a mobile device.
Most servers (1) are not CPU bound and (2) experience bursty load, and thus can absorb GC expense while blocking on I/O and/or in the quite microseconds between requests.
When servers do become CPU or RAM bound, one can always add more nodes — and for most companies, that’s cheaper than paying for more developer effort.
Servers tend to have a pool of long-lived, relatively static allocations, plus a rapid stream of short-lived allocations that last only as long as single requests. This duality maps neatly to generational garbage collection.
Furthermore, a server wants to get a response out the door as fast as possible when a request comes in, and it thus makes sense to defer ref counting and deallocation costs for those short-lived allocations — exactly as GC does — until after the response goes out, even if that comes at the cost of RAM and greater total CPU usage.
This high turnover also mitigates (though does not eliminate) the problem of cache thrash. The objects in the short-term pool tied to request lifecycle that GC needs to traverse frequently aren’t going to live long anyway, so there’s less value in keeping them cached.

Yes, maybe our data centers would be greener if we all ditched GC entirely, but the bottom line is that right now, the developer productivity advantages of GC clearly outweigh the costs … on the server. As long as our time remains expensive and servers and electricity remain cheap, this will remain true.

That whole equation changes on mobile devices.

Jean-Denis mentioned “our Apple island” where GC is frowned upon. It’s not just Apple. That island has other inhabitants: video game developers. That’s illuminating, and in ways that extend beyond memory management. One of the original brilliances of the iPhone was that it realized mobile apps have more in common with video games than with the enterprisey fill-in-the-text-field apps that are the home base of most UI stacks. This insight pervades the platform, and is a lot of what makes the iOS devices feel as polished as they do.

GC is probably not right for iOS devices, or for Swift. Swift made a mindful tradeoff here, and it was probably the right tradeoff. However, we should remember that there was a tradeoff, and keep an eye on what we gave up.

• • •

That said, I was a little surprised to hear Chris Lattner rule out any form of cycle detection for Swift. I figured that it might eventually arrive in some form, albeit limited.

No time for it at the moment, but I have some thoughts about places where the lack of GC gets in the way of clean code and good abstraction. Closure captures are one such pain point.

It would be nice examine those problems and tackle them in the Swift spirit of “look like high level, compiles like low level” abstractions.

• • •

> On Feb 9, 2016, at 9:32 AM, Ondrej Barina via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

Radek did not say “does not have performance problems.” His words were:

>> much less of an issue for server side stuff

…and he was correct. Ondrej, it sounds like you’re in one of the rare situation where CPU and RAM really are the bottlenecks in the server farm. That’s not typical in my experience.

Cheers,

Paul

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