Re: Avoiding mutual retain cycles
Re: Avoiding mutual retain cycles
- Subject: Re: Avoiding mutual retain cycles
- From: Marcel Weiher <email@hidden>
- Date: Tue, 22 Jul 2008 17:10:18 -0700
On Jul 22, 2008, at 11:52 , Philippe Mougin wrote:
Le 22 juil. 08 à 06:21, Marcel Weiher a écrit :
http://portal.acm.org/citation.cfm?id=1035292.1028982
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”."
Yes, it is a very interesting read, as are some of the related
articles that describe cycle-collectors.
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.
Semi-manual, yes. However, the "automation" axis is actually distinct
from the "tracing vs refcounting" axis, which is something that is
often misrepresented (not that you did): a distinction is made
between "reference counting" and "GC". This distinction is not valid,
both refcounting and tracing are forms of GC, there is no "in-
principle" difference in capabilities, just choices made by specific
implementations.
To illustrate, I automated my reference counting a long time ago,
through both coding-practices and actual code:
1. Only use accessors to set ivars (in general: to access), including
during object creation [coding practice)]
2. Automate accessor generation ( accessor-macros in my case,
@properties have a similar effect) [code]
Those two elements largely eliminated reference counting from my code-
base, meaning that code generally looks the same as it would with a
(tracing) GC. There are only 2 elements left: the -dealloc method
and cyclic references, with the latter being the original subject of
this thread. I actually also addressed those two, at least in
specialized circumstances, through some more code:
3. Automate the '-release' messages sent from -dealloc via some
introspection [code]
4. Build a cycle collector [code]
With those two additional elements in place, the RC implementation
becomes completely equivalent in functionality and convenience to a
tracing collector, with the differences now implementation choices
that affect such things as performance profiles and malleability.
I actually don't use 3+4 in most of my code (4 being part of my
Postscript interpreter), but they do show that the theoretical
equivalence given in the paper is not just a theoretical result, but a
practical option. It just turned out that neither dealloc methods nor
cyclic references were enough of a problem for me in the general case
in order to invest more time in 3+4.
But this was a purely pragmatic choice, not an in-principle limitation.
Cheers,
Marcel
_______________________________________________
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