[Haskell-cafe] Automatic Reference Counting
Thomas Schilling
nominolo at googlemail.com
Sat Jul 2 18:18:56 CEST 2011
Reference counting usually has much higher overheads than garbage
collection and is tricky to parallise. It's main advantage is quicker
release of memory.
I believe the main feature of ARC is that the user does not need to
manually keep reference counts up to date. I heard from people using
CPython (which uses reference counting) as a library from C that it's
very easy to accidentally forget to update the reference count
correctly. With ARC the compiler takes care of it, so there's less
opportunity for mistakes. ARC also optimizes away redundant reference
updates within a function (Haskell functions are usually small, so I
don't know how well that would work).
The reason why reference counting is usually slower is:
- Say you update a field "f" of object "o" from pointing to "a" to
pointing to "b". This entails three memory writes instead of one,
because you also need to update the reference counts of "a" and "b".
- You also need some extra space to store the reference counts.
- You need to take special care to avoid cascades to avoid
occasional long pauses. E.g., if an object's reference count goes to
zero, that will cause all objects pointed-to by that object to be
decreased. This might cause another object's reference count to go to
zero etc.
- You need a backup tracing collector to collect cycles as you mentioned.
There are many optimizations possible, e.g. delayed reference
counting, but AFAIK reference counting is in general slower than
tracing GC. It does get used in situations where quicker resource
release and more predictable GC pauses are more important than
absolute performance (or peak throughput).
On Sat, Jul 2, 2011 at 16:51, Thomas Davie <tom.davie at gmail.com> wrote:
> Hi guys,
>
> Apple recently announced a new static analysis in Clang called ARC (Automatic Reference Counting). The idea is to provide what GC provides (zero memory management code by the programmer), but not to incur the runtime penalty of having to have the GC run. It seems to be extremely effective in objective-C land.
>
> I was wondering if any of the compiler gurus out there could comment on the applicability of this kind of analysis to Haskell. Dropping the GC and hence stopping it blocking all threads and killing parallel performance seems like nirvana.
>
> The one major problem that's still left with ARC is that it does not solve the retain cycle problem of reference counting. Programmers must insert a "weak" keyword to break cycles in their data graphs. Could even this analysis be automated statically? Could we put up with a language extension that added this annotation?
>
> I'd love to hear some comments from people more-experienced-than-I on this.
>
> Thanks
>
> Tom Davie
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
Push the envelope. Watch it bend.
More information about the Haskell-Cafe
mailing list