Hacker News Reader

Comment by janardanyri | Hacker News Reader

> The mobile vendors have all gone with GC.

It's a minor point, but Apple created ARC specifically as a streamlined reference counting alternative to GC, which was never used in iOS and is now deprecated in Mountain Lion.

View on HN

I do count ARC as a form of GC. The test is if the developer has to manually litter their code with calls to release/free memory.

You do not need to do so in Android (Java), iOS (ObjC), Windows Phone (C#) etc.

You're right. But on iOS, we still have to think about it a little bit. Maybe not with malloc and free (or retain/release, actually), but in terms of object graph (we can't have "retain cycles", or "strong reference cycles", as they are called in ARC).

It's a minor point and I agree with what you said, but I wanted it addressed in case someone who've not familiar with ARC gets the wrong impression :)

These terms have basic meanings that are independent of what you seem to wish they meant. GC is not reference counting, and it would benefit you to put he difference in your memory.

I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?

While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.

Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones:

* their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare)

* a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register)

* none of the locality advantages of copying/compacting collectors

Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management).

GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.

Garbage collection seems to be a synonym for automatic memory management for many people. Some even see RAII in C++ as GC. I guess GC is so meaningful for many programmers as it is really convenient, that it has become the main word for AMM; as Google is to searching the web.

http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...

I am aware of the Wikipedia link. It also has no references, and is marked as being original content.

What term should we use to discuss garbage collection schemes that impose a real time overhead (those systems virtually everyone means when they say they dislike GC) and memory management schemes that involve no runtime overhead?

Reply on news.ycombinator.com