Hacker News Reader

Comment by schrototo | Hacker News Reader

iOS 5 doesn't have garbage collection, it has a new compiler-level feature called Automatic Reference Counting which does pretty much what you think it does. It's basically retain/release without you having to explicitly write retain/release instructions.

(I don't think I'm violating any NDAs here, since ARC was up pretty big on one of the slides at the keynote. In any case, anybody who cares about this stuff is either at WWDC or at least has a dev account and has been pouring over the beta docs since they've gone online.)

View on HN

ARC is touted on this public page: https://developer.apple.com/technologies/ios5

That's a... peculiar choice of icon.

edit: ah, now I get it. Cute.

I don't get it :( please explain.

It's an arc.

When electricity moves through the air between two points like that its called an arc. (look up electric arc on youtube for examples)

Oh, so it isn't a visualization of how ARC works. It's just an image of something else that coincidentally has the same name. I would've never figured that out. Thanks.

I think this is actually a bigger deal from a developers perspective than most of the other announcements. Since it's a compiler feature, does anyone know if it's compatible with older os releases?

Once you're familiar with the manual memory management conventions, it's not difficult, but this should make iOS development more approachable.

"ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. (Weak references are not supported in Mac OS X v10.6 and iOS 4)."

But how about looking at the docs yourself?

Aren't they behind a password/NDA wall? Perhaps I didn't see that information when I was looking at it?

I'm sorry, I didn't mean to be snarky. (Although if you're not a member of the dev program, I don't see why you care about this information?)

Any new platform that isn't ultradoomed is interesting. I might have been waiting for iOS development to become less brittle before getting involved (that is, if their policies towards developers and users weren't so repellent).

I'm not sure why you would say this isn't garbage collection. It performs automatic management and reclamation of resources without programmer intervention. It doesn't operate like the GC's of the JVM or .NET CLI, but then neither to the GCs for other languages like Lua, Python, or Perl.

Python has a proper GC to remove cycles in reference counting, it's just not the "main" one.

http://docs.python.org/library/gc.html

  Since the collector supplements the reference counting already used in Python, you can disable the collector if you are sure your program does not create reference cycles. Automatic collection can be disabled by calling gc.disable().

> I'm not sure why you would say this isn't garbage collection.

Because it isn't. Garbage collection is something that happens at run time by a garbage collector via an algorithm like mark-and-sweep, tri-colour marking, etc, and as a block of code that's called at runtime it A) has a lot of information about your program and B) has a nontrivial performance impact.

Unfortunately I can't talk specifics (stupid NDA), but schrototo has said that it's a compiler-level feature, which would automatically disqualify it as being a bona fide garbage collector.

Speaking generically, any static feature is going to a great deal less powerful than its dynamic equivalent. Thinking of compile-time memory management as garbage collection is not just a leaky abstraction, it's a broken water main flooding into the street.

Think less "auto pilot" and more "cruise control". You still have to understand the accelerator and the break, you just don't have to use them as much.

A garbage collector doesn't need to use an algorithm like mark-and-sweep, or two space copying. It can be something as simple as a system that scans a block of memory looking for any sequence of bytes that appears to be a pointer into managed memory. You don't need special compiler support or extra program knowledge for garbage collection -- conservative collectors can be added to any language, like using the Boehm-Demers-Weiser GC with C or C++.

Automatic garbage collection doesn't even require a garbage collector -- the monolithic piece of code that performs the scanning and reclamation of objects -- it simply requires freeing the programmer from the task of managing the storage of an object. Fancy collector algorithms are meant to improve throughput and latency -- you could definitely create an implementation of Java that uses automatic reference counting but you'd be searching for something faster really quickly.

If I have a language where I create a number of managed objects and the compiler's escape analysis determines that these objects never leave the function's scope and so changes them to be an alloca then you would have garbage collection without involving a garbage collector.

Again, if that's what automatic reference counting is as sold by Apple then I'd consider it to be garbage collection.

For what it's worth, Apple sees this as distinct from garbage collection. For new projects they recommend using ARC, even on the Mac where "real" GC is (and will continue to be) available.

Are you willing to elaborate on this? Recommending it over garbage collection on OS X would run contrary to their previous evangelism of GC and its concurrent scalability.

I can't, since I don't know any more than the next guy reading the docs. I'm sure there'll be an in-depth WWDC session on this and I'm eagerly awaiting the videos.

(I haven't done any Mac OS programming with GC, so I really don't know anything about it, but I've always heard people say the GC is not all that great. So my own uneducated guess is that while GC is messy and complicated, ARC is simple & doesn't have any runtime overhead (they say in the docs that retain/release is now much faster, as is autorelease using the new syntax).)

> Automatic garbage collection doesn't even require a garbage collector -- the monolithic piece of code that performs the scanning and reclamation of objects -- it simply requires freeing the programmer from the task of managing the storage of an object.

Can you back that up? I'd like to see a source that disconnects garbage collection the feature from a runtime garbage collector the implementation of that feature.

Independent of the semantic dispute, I don't think you understand what ARC, the iOS 5 feature, actually is. It's not a technology that "frees the programmer from the task of managing the storage for an object". Just to start with, that is a decision that can only be made at runtime, and as has been discussed ARC is a static-time feature.

Reference counting is very definitely a form of automatic memory management, aka GC. Every GC expert will disagree with your colloquial definition. There are two sides to every reference - the guy who has the pointer and the thing pointed to - and the most efficient GCs use a combination of both. The difference is that the "logical ref count" is distributed for mark-sweep etc, but centralized in object for refcounting.

We're talking past each other. There's "Automatic reference counting, the dynamic garbage collection algorithm that runs periodically at runtime during your program's execution", and "Automatic reference counting, the static compile-time feature that ships in iOS5."

These two things unfortunately share a name, but absolutely nothing else. The iOS 5 feature is not, and has no relationship to, and does nothing remotely like, the garbage collection algorithm with the same name.

One reason is that reference counting, without some other backup reclamation mechanism, isn't guaranteed to collect all the garbage. For example: let's say you have two DOM nodes, A and B, where B is A's firstChild and A is B's parentNode, with both attributes implemented as references in the obvious way. Even if all other references to these objects disappear, making them both inaccessible, the reference from child to parentNode will keep the parent's reference count from going to zero until the child node gets reclaimed --- but the child node can't be reclaimed until the parent is gone, because the firstChild reference in the parent keeps _its_ reference count from going to zero. So neither object can be reclaimed first (or at all), and the storage for both leaks.

(The same logic applies to longer "cycles" of references --- if A refers to B refers to C refers to D refers to A, then none of the objects in the cycle can be collected first, and they all stick around.)

In CPython, by the way, there is a separate garbage collector, which runs periodically to detect and mop up cyclic structures. Other implementations --- Jython and PyPy --- don't use reference counting to begin with.

And if the values being garbage collected have no pointers in them, or the language makes cycles impossible (think functional immutable) the refcounting is all you need. It's still bona fide GC.

(This is a point of definition independent of the subject at hand. Refcounting simply is a form of GC. Imperfect for most languages and many datatypes but GC all the same.)

Garbage collection specifically refers to a collector that reclaims resources at run-time (the "garbage"). According to the article, this is static analysis that inserts retain/release into the code at compile-time.

Isn't "automatic reference counting" just a specific type of "garbage collection"?

But yes, I think this feature really slipped through the cracks in the announcements I've seen so far (even Ars seemed confused about it)

I think this is done at compile time, so it wouldn't be considered garbage collection.

The compiler is LLVM though, "By enabling ARC with the new Apple LLVM compiler", which begins to blur the difference

I don't think that makes much difference, as long as it's performed at compile time.

LLVM is being used as a static compiler. There is no LLVM virtual machine - the compiler emits native machine code.

MacRuby does support AOT compilation, although I don't think it's a very production-ready feature yet and would likely be incompatible with a fair percent of existing ruby code

This isn't in MacRuby — it's in Objective-C. And it's explicitly distinct from garbage collection. This is an alternative to garbage collection that has generally been considered kind of impractical.

(And MacRuby's AOT compilation works pretty well from what I've seen.)

it depends. If it copes with circular references, then yes, it is suffiecient to use for gc.

If not then it's just what COM had.

Unfortunately, it doesn't handle cycles in the object graph[1], which was almost the entire reason I wanted GC. Manually dealing with cycles is one of the worst parts of working with blocks (the other is the lack of parameterized types).

Assuming that ARC works reliably and consistently, it'll be nice to lose some boilerplate, but the worst facet of reference counting -- object graph cycles -- still isn't fixed.

[1] There is support for zeroing weak references, but this is a very manual solution to the cycle problem.

That basically makes it useless. It would be an utter pain in the arse finding leaks in. I don't know why they cant chuck a generational collector in it such as the one in the last ObjC drop in it. Even microsoft with the woefully inadequate WM7 platform has a proper GC.

I wouldn't say useless -- just a lot less useful. Maybe they'll add cycle handling on top of it later.

Reply on news.ycombinator.com