[swift-evolution] What about garbage collection?

David Owens II david at owensd.io
Wed Feb 10 03:03:18 CST 2016

> On Feb 9, 2016, at 11:50 PM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
> It does break the make it easy to debug rule though. In any non trivial system worked on by a moderate to large team, manually hunting cyclic references and appropriately breaking them down without introducing bugs can still be very painful. GC is one of those technologies where you trade the efficiency you mention for a safer and easier to use memory model where you would spend a lot less time to debug for correctness.

And this is replaced with analyzing performance profiles to understand why sporadic slowdowns are happening. Then you find that too many allocations of objects are being created causing the GC sweep to take longer than is acceptable. Now you need to try and preempt the GC sweep by triggering it sooner or pausing it all together. The other option is trying to fix what is most likely an architectural issue with the allocation graph. One way to do that is to go about creating pools of objects that no longer have real-lifetimes according to the GC because they are always alive and just marked as inactive.

That's just a sample of real-world performance analysis I used to do on the Visual Studio team when we starting using a bunch of managed code (C#) in it. 

Another is simply not understanding what types of things hold onto objects so that they are never collected. C# has a problem (or did at least when I was still using it) with this and its eventing model. If you forget to unregister the events, then good luck getting that memory back. Or if one thing somewhere in your code is holding a reference to your giant data structures - nope, not going to get collected.

The point is, even with a GC, you still need to be conscious about what's going on.

It's simply not been my experience that debugging the type of issues you run into with a GC are significantly easier than a non-GC system. In fact, in many ways they are harder as often times the solution is to architecture around the limitations of the GC.


More information about the swift-evolution mailing list