Re: ARC replacing GC?

On Jun 15, 2011, at 10:39 PM, Quincey Morris wrote:

If you're familiar with ObjC GC, ARC brings support for Zeroing Weak pointers to ARC mode as well, which is a really great way to handle cyclic references.

So I went and read more about it there, and that document provoked the following questions/comments:

1. It's clear from the document that there are certain coding patterns that are unacceptable to ARC, and that's fine. What's not clear is what general application design characteristics are inappropriate for ARC. I mean, how do I decide, when starting a new application, whether I am going to be able to use ARC or whether I need to do something else?

All of the new project templates in Xcode 4.2 default to ARC. We recommend its use for all new code and provide an semi-automated migration tool for moving retain/release code to ARC. In time we'll extend it to also support migrating GC apps for people who are interested.

2. What's the functional and/or design benefit from using GC instead of ARC, if there is one? I mean, are there specific high-level application characteristics that would lead to a decision to use GC rather than ARC? (Or manual retain/release memory management instead of ARC.)

The primary advantage of GC over ARC is that it collects retain cycles. A secondary advantage is that "retained" assignments are "atomic" because they are a simple store.

ARC has several big advantages over libauto GC:

1. It has deterministic reclamation of objects (when the last strong reference to the object goes away) where GC frees an object "sometime later". This defines away a class of subtle bugs that can exist in GC apps that aren't exposed because the collector doesn't trigger "in the buggy window".

2. The high water mark is generally much lower with ARC than GC because objects are released sooner.

3. libauto provides a fragile programming model, you have to be careful to not lose write barriers etc.

4. not all of the system frameworks are GC clean, and the frameworks do occasionally regress as they evolve.

5. ARC doesn't suffer from false roots. libauto conservatively scans the stack, which means that integers that look like pointers can root object graphs.

6. ARC doesn't have anything that kicks in and stops your app, causing UI stutters. libauto is pretty advanced as far as GC implementations go because it doesn't immediately stop every thread, but it still does usually end up stopping all the UI threads.

3. I was left wondering why ARC isn't actually a hybrid ARC/GC technology. Low level technical details aside, they seem to be perfectly matched, in the sense that most memory management is effectively handled by ARC, but pairing it with GC would cover at least some cases that would defeat ARC (such as retain cycles that for one reason or another aren't broken by weak references). If ARC could remove most memory scanning from the realm of GC, it seems that GC's most significant drawback -- performance penalties -- might well be eliminated.

It's fully possible to introduce a cycle collector into ARC, but we don't think that this is a good idea, at least not now. If this exists, then apps can come to accidentally depend on it, and you effectively have a poor GC system. Instead we've provided two tools, which are pretty great:

1. zeroing weak references, which are like assign properties in their cycle breaking ability but a lot safer since they can't dangle.

2. improved instruments support for detecting retain cycles (which I won't talk about here because it's technically covered under the wwdc NDA)

4. It's striking that the above-linked document is very careful to spell out how syntactic changes to Objective-C are used to guarantee the near-correctness of runtime behavior. In the few cases where the developer is exposed to some slight risk, the rarity or dubious value of the risky scenario is explained. AFAICT from just reading the document, it's a very temperate approach.

We really want to provide a robust model, and to make it clear when things are potentially dangerous are happening in the code. This is why we spell things like __unsafe_unretained, and why the casts need to be explicit now.

What bothers me is that we're several years into to the Objective-C GC era, and there are risky scenarios in developing for GC that are not dubious, or rare to the same degree. If "you" (whoever the responsible parties are) are prepared to enhance the Objective-C language with new elements whose purpose is to allow developers to express their memory management intent, thereby rendering ARC pretty much completely safe for all practical purposes, AND "you" are prepared to justify both the need for those elements and the resultant safety, then what does it mean that the corresponding issues in GC are still left out in the cold? Why don't "you" go back and lavish the same sort of care on the pitfalls of GC that "you" are apparently willing to lavish on ARC? I find this rather puzzling. Are we being punished for having adopted GC wholeheartedly??

I don't have any comment on GC, other than we continue to support it on Lion.

-Chris

References:
	>Re: ARC replacing GC? (From: Gordon Apple <email@hidden>)
	>Re: ARC replacing GC? (From: Joar Wingfors <email@hidden>)
	>Re: ARC replacing GC? (From: Chris Lattner <email@hidden>)
	>Re: ARC replacing GC? (From: Quincey Morris <email@hidden>)