Realtime, GC and ObjC (Was Re: Opinion on managed memory and garbage collection)
Realtime, GC and ObjC (Was Re: Opinion on managed memory and garbage collection)
- Subject: Realtime, GC and ObjC (Was Re: Opinion on managed memory and garbage collection)
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 23 Jun 2009 09:53:17 -0500
On Jun 23, 2009, at 1:39 AM, Chris Idou wrote:
I haven't noticed GC pauses. It seems to me that the GC collects
memory extremely quickly, relative to when it becomes unreachable.
Given that it apparently does a lot of work in another thread, I
wouldn't expect there to be much pausing in "normal" applications.
Good. Then it is behaving as designed. And the pauses are shorter
and fewer in Snow Leopard. Expect the trend to continue.
One of the concerns I see with GC is "I can't use it because my app is
realtime or near-realtime". In this case, GC or not is moot and the
real issue is that you can't use Objective-C for realtime uses.
And, by "realtime uses", I really mean "you can't use Objective-C or
CoreFoundation in a thread that requires near-realtime
servicing" (since there is no support for real-realtime services in
Mac OS X).
Any invocation of objc_msgSend() can block and/or allocation memory.
It doesn't happen often, very rare actually, but it *can* happen and
*will* happen when something causes various method caches to be
flushed and repopulated.
Since a bunch -- and growing portion -- of CoreFoundation is
implemented using Objective-C, you can't use CF either.
However, this isn't really the bugaboo that it sounds like. The
reality is that if your app has some particular subset of behaviors
that are so terribly time sensitive -- of which there are a number of
perfectly valid reasons why that might be -- that you need pretty
close to realtime behavior, then you need to isolate said behavior(s)
as much as possible.
This means:
- stick the behavior(s) in a thread that does as little work as possible
- don't do any allocaitons; pre-allocate all the buffers you need
- don't do any locking; use lockless algorithms for push/pull of the
data
- don't use any system APIs except exactly what is needed
And that is overly-simplistic, of course.
One last really big caveat: Do not assume that you need to avoid ObjC/
CF/GC/sys until you can prove that you really need to.
b.bum
_______________________________________________
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