On Mar 13, 2009, at 2:28 AM, Paul Sanders wrote:
Having said all of which, I think the original test is not unfair
and I
agree with a lot of the points people have made in support of that
view.
It's always painful to have to step outside the Cocoa frameworks,
and (off
topic) it seems that GC can make it more so. I for one will not be
using
it.
Having written a ton of code that sits on the border between GC and
non-GC, I don't find that GC makes the code any more difficult to
write along that particular border. It does, however, make it
considerably more difficult to debug certain kinds of problems related
to memory management (and this is an area for which a lot of effort
has been expended to improve the experience on Snow Leopard -- if you
have access to the seed, please go poke at it and provide feedback).
Under non-GC, that border is either:
- retain/release/autorelease vs. cfretain/cfrelease
or
- retain/release/autorelease vs. malloc/free
or
- retain/release/autorelease vs. some random memory management module
specific to C++ and/or library you are working with
Under GC, the retain/release/autorelease part goes away, obviously.
This leaves the right hand side relatively unchanged saved for where
it integrates into the code. The most complex change is the move
from -dealloc to -finalize. Finalizers are executed in an
effectively random order whereas many people seem to want deallocs to
be executed in a fixed, dependent, order.
In reality, incurring order dependencies on -dealloc is a really bad
idea; one unexpected -retain [leak] or -autorelease [order change]
and the house of cards falls over (this has been a *huge* debugging
time sink, in my experience). Finalizers force the issue by making
ordered execution nearly impossible to achieve.
---
Beyond owning non-GC'd stuff in GC'd memory, there is the reverse
issue. There is virtually no difference between non-GC and GC in
this regard. If you are shoving a random object reference into non-
ObjC data structures, through non-ObjC APIs, under non-GC, you need to
-retain on entrance and -release on exit to be safe. Whether you
call -retain/-release in your wrapper around the non-ObjC API or
modify the non-ObjC API to call -retain/-release internally is
entirely an implementation detail.
Moving to GC doesn't really change anything beyond the need to use
CFRetain() / CFRelease() instead of -retain/-release. Since you can
use CFRetain/CFRelease in the non-GC case, replacing -retain/-release
in such contexts (-autorelease is generally to be avoided in such
places with CFRetain/CFRelease makes for nearly no difference.
Of course, you could choose to go down the route of using the various
APIs to allocated collectable/scanned memory while using __strong and
__weak to make the non-ObjC code more GC friendly. There will be an
ever growing performance gain to be had in doing so, but it is very
hard to get right. (The ObjC garbage collector is not actually an
ObjC garbage collector -- it is entirely language agnostic. The
"ObjC" part is that it is fully automatic with Objective-C, but must
be manually integrated with everything else.)
---
Thus, it comes down to an issue of debugging. And, frankly, in
Leopard, debugging that border is hard. Harder than non-GC, but not
significantly so. In both cases, the use of
MallocStackLoggingNoCompact, the resulting malloc histories, and
related tools is critical. The bugs at the border will typically be
premature destruction of memory and knowing the history of a pointer
that causes a crash later will typically point to exactly where the
premature destruction occurred.
As you said, going from Cocoa to non-Cocoa is a pain. GC changes the
pain a bit, making it slightly worse in some ways.
Personally, I find that developing Cocoa applications using GC is so
much faster and more pleasant than non-GC, that the relatively minor
additional border pain is easily outweighed by the advantages of using
GC on the pure Cocoa side.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
