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: "Michael Ash" <email@hidden>
- Date: Wed, 6 Feb 2008 16:38:02 -0500
On Feb 6, 2008 3:23 PM, glenn andreas <email@hidden> wrote:
> Regardless, all objects must start with that isa pointer - the runtime
> requires it. Objects _are_ special, and pretending that this is just
> another arbitrary struct is incorrect:
> 1) They can't live on the stack
This is a bit nitpicky, but they can:
struct { Class isa; id ivar; } fakeObj;
fakeObj.isa = [SomeClass class];
id fakeObjPtr = (id)&fakeObj;
[fakeObjPtr myCustomInitializer];
Of course you have to ensure that the layout is correct, and you can't use
this with any Cocoa classes since you completely break Cocoa's idea of
initialization memory management, but it works fine with classes which are
100% custom (i.e. do not have Cocoa anywhere within their inheritance chain)
as long as they understand stack semantics. You can fix the layout problem
in 32-bit by using @defs, but in 64-bit land you'd have to fall back to
trickery with alloca or C variable-length arrays, neither of which is going
to be much fun.
The Stepstone compiler explicitly supported stack objects by doing the
obvious thing and leaving out the * when declaring a local object variable.
Obviously gcc doesn't support this though.
2) They have a special isa pointer
> 3) They have implicit requirements to be allocated/copied/released
> using special routines (NSAllocateObject, NSCopyObject,
> NSDeallocateObject) - i.e., it's unclear if you attempted to malloc or
> new a structure of the same type and manually filled in the isa
> pointer would necessarily work on current or future Objective-C
> runtimes (it would almost certainly fail under 64 bit Objective 2.0)
As far as I know, the only tricky thing about the 64-bit runtime is that you
can't calculate the amount of storage required at compile time.
Once you have an object, the only thing that really cares about it is the
objc_msgSend family of functions and ivar access. objc_msgSend only cares
about the isa pointer which will still be there as long as you set it up
properly, and ivar access, even in 64-bit land, is just accessing memory at
an offset to the self pointer. Cocoa classes have certain memory management
requirements but ObjC classes do not. You can write your own class hierarchy
which uses malloc/free, new/delete, mmap, or any other memory allocation
technique and it will work fine. You'll lose out on garbage collection, but
that's to be expected when you start doing custom memory allocation.
I would not recommend actually *doing* any of the above, but there's a
fairly wide space between what's reasonable to do and what's possible to do.
Digressing slightly, it would be nice if NSObject would offer separate
deinitialization and deallocation methods to match the separate
initialization and allocation methods so that it would be possible to
implement a custom memory allocation scheme in an NSObject subclass. As it
stands, you either have to implement your own root class, or you have to
subclass directly from NSObject and assume that its dealloc method does
nothing other than free the object's memory.
Mike
_______________________________________________
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