Re: In-loop releasing of objects does not free memory?
Re: In-loop releasing of objects does not free memory?
- Subject: Re: In-loop releasing of objects does not free memory?
- From: Jim Correia <email@hidden>
- Date: Fri, 15 Feb 2008 12:15:25 -0500
On Feb 15, 2008, at 11:27 AM, Adam P Jenkins wrote:
On Feb 14, 2008, at 10:57 PM, Jim Correia wrote:
But -release is a no-op in GC code. NSAutoreleasePool will never
get the message. So we need a new message that we can send
NSAutoreleasePool that it will actually get when running in GC
mode. And for convenience, in non-GC mode it should do the same
thing as -release always did, to provide a single, simple idiom for
inner autorelease pools that will work in either GC or non-GC mode.
Yes, strictly speaking, it is inconsistent. But also necessary; the
alternatives would be uglier.
I still don't understand. Why does it matter that the release
message to a NSAutoreleasePool would be a noop when running in GC
mode? Isn't autorelease also a noop? In which case the whole
NSAutoreleasePool is just a noop, since nothing would ever actually
get added to it. So I still don't understand the need for the drain
method as it's currently defined.
There aren't any autoreleased objects in a GC app in the traditional
sense, but there will be uncollected garbage.
-drain provides a single mechanism which you can use in a tight loop
which generates lots of temporary objects to
- in GC mode hints to the collector that it should collect some garbage
- in non-GC mode, pop the autorelease pool
which have similar effects on the high water mark of helping you keep
down your high water mark.
Clarifications or additional explanation from the obj-c GC designers
welcome :-)
Jim
_______________________________________________
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