Re: Avoiding mutual retain cycles
Re: Avoiding mutual retain cycles
- Subject: Re: Avoiding mutual retain cycles
- From: Philippe Mougin <email@hidden>
- Date: Tue, 22 Jul 2008 20:52:01 +0200
Le 22 juil. 08 à 06:21, Marcel Weiher a écrit :
On Jul 21, 2008, at 13:03 , Philippe Mougin wrote:
Le 21 juil. 08 à 20:50, Markus Spoettl a écrit :
I'm wondering if there is a general rule or mechanism that
suggests what to do in such a case. For instance, how are
delegates implemented in AppKit, are they retained? If so, when
are they released. It can't be in -dealloc, otherwise everything
would lock itself out of deallocation?
In the general case, there is no rule or mechanism to deal with
retain cycles other than implementing something equivalent to a
garbage collector. In some situations, however, the specific
semantics and life-cycle of the objects you are dealing with allow
implementing more simpler, ad hoc solutions (e.g., ownership
management in the view hierarchy). Still, this requires notable
housekeeping efforts and is often error prone. If you are in a
situation where you can make use of Cocoa's garbage collector, you
should go for it. It will free you from a bunch of low-level memory
management tasks, including having to care about cyclic references.
http://portal.acm.org/citation.cfm?id=1035292.1028982
"Tracing and reference counting are uniformly viewed as being
fundamentally different approaches to garbage collection that
possess very distinct performance properties. We have implemented
high-performance collectors of both types, and in the process
observed that the more we optimized them, the more similarly they
behaved - that they seem to share some deep structure.
We present a formulation of the two algorithms that shows that they
are in fact duals of each other. Intuitively, the difference is that
tracing operates on live objects, or "matter", while reference
counting operates on dead objects, or "anti-matter". For every
operation performed by the tracing collector, there is a precisely
corresponding anti-operation performed by the reference counting
collector.
Using this framework, we show that all high-performance collectors
(for example, deferred reference counting and generational
collection) are in fact hybrids of tracing and reference counting.
We develop a uniform cost-model for the collectors to quantify the
trade-offs that result from choosing different hybridizations of
tracing and reference counting. This allows the correct scheme to be
selected based on system performance requirements and the expected
properties of the target application."
Well said!
There are also interesting bits in their conclusion:
"This explains why highly optimized tracing and reference counting
collectors have surprisingly similar performance characteristics.
In the process we discovered some interesting things: a write barrier
is fundamentally a feature of reference counting; and the existence of
cycles is what makes garbage collection inherently non-incremental:
cycle collection is “trace-like”."
Of course, in Objective-C, one must keep in mind that while they share
some "deep structure", the reference counting model we have is manual
whereas the tracing collector is automatic.
Philippe Mougin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden