re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: Ben Trumbull <email@hidden>
- Date: Mon, 4 Feb 2008 01:19:42 -0800
- Resent-date: Mon, 4 Feb 2008 01:20:51 -0800
- Resent-from: Ben Trumbull <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Cocoa-dev list <email@hidden>
[and to the list]
You'll want to read this:
<http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html
>
On the first page, it says:
"The initial root set of objects is comprised of global variables,
stack variables, and objects with external references. These objects
are never considered as garbage."
The key point here is "stack variables" include everything that thread
is referencing on any of its stack frames or registers.
This information is essentially impossible to know apriori,
No, it's not a quality of the dynamic allocation, it's a quality of
the class's ivar. Should title be scanned ? Yes ? No ?
Practically speaking, Objective-C objects are allocated from scanned
memory, and the system frameworks Do The Right Thing. If you call
malloc() yourself, well, that's clearly not from GC's scanned memory.
so the only practical course of action is to defensively qualify all
pointers as __strong.
That's probably wise for people learning to use GC.
I believe I have a succinct example that illustrates these issues:
... you did it wrong and it doesn't work. Check.
but it's easy to think of examples where the pointer passed to a C
function, say an SQLite3
call, can cause no end of problems if that pointer happens to be
reclaimed in the middle of the function call.
As it just so happens, I write a dual mode framework that does exactly
that.
This is beyond non-trivial in practice as the passing of pointers is
part of most functions calls.
Arguments and return values are always live as they are on the stack
(or a register). If one of those functions wants to store the pointer
in its own memory, then you need to keep that pointer live for however
long you expect the C library to reference it. Which isn't any
different than life before GC.
- Ben
_______________________________________________
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