Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: "Joan Lluch (casa)" <email@hidden>
- Date: Sun, 6 Jul 2008 00:00:36 +0200
El 04/07/2008, a las 22:54, Chris Hanson escribió:
On Jul 4, 2008, at 2:25 AM, Joan Lluch (casa) wrote:
First, GC makes programs go slower not because of the overhead of
the garbage collection itself, which I concede that may be
comparable to the retain/release calls in a non-managed
environment, but for the extra memory overhead that it is used. The
crucial difference between a non-managed app and a GC app is that
in a non-managed app the memory is released very soon after the
life of an object has expired.
Please do not spread misinformation about Objective-C garbage
collection. What you're essentially asserting is that Objective-C
garbage collection will always increase the high-water mark of an
application, and that is not the case.
Memory in a GC app is released very soon after the life of an object
is over -- sometimes, even sooner than it would be under manual
memory management. That's because Objective-C garbage collection
runs on a separate thread.
Under non-GC, an object's memory may not be reclaimed until the
current autorelease pool is drained. However, under GC, an object's
memory can be reclaimed as soon as the collector can tell there are
no more references to it -- no matter when that is.
-- Chris
Sorry if I my post did not sound appropriate. It never was my
intention. However, let me copy an excerpt of the Cocoa documentation
on the GC algorithm that Cocoa uses. This is *exactly* what the
collector does and this is why the memory used by a GC app is *that*
much compared to a well designed traditional Cocoa app.
<begin excerpt>
The collector is conservative—it never compacts the heap by moving
blocks of memory and updating pointers. Once allocated, an object
always stays at its original memory location.
The collector is request-driven, not demand-driven. The Cocoa
implementation makes requests at appropriate times. You can also
programmatically request consideration of a garbage collection cycle,
and if a memory threshold has been exceeded a collection is run
automatically.
The collector runs exclusively on the main thread of the application.
At no time are all threads stopped for a collection cycle, and each
thread is stopped for as short a time as is possible. Threads may be
blocked for a short time while all unreachable objects are formed into
the garbage list and weak references zeroed. Only threads that have
directly or indirectly performed an[NSThread self] operation are
subject to garbage collection.
The collector is generational (see “Write Barriers”)—most collections
are very fast and recover significant amounts of recently-allocated
memory, but not all possible memory. Full collections are also fast
and do collect all possible memory, but are run less frequently, at
times unlikely to impact user event processing, and may be aborted in
the presence of new user events.
<end>
Basically for performance reasons, the G. collector "preffers" to let
memory usage grow (while it is still available) in order to avoid too
many collections or to try that the user does not notice it, and in
practice it generally succeeds at it. But you will definitely notice
some annoying sporadic app response delays of half a second or so
specially if your app is very complex and maintains lots of objects
referencing each other in complex graphs.
On the other hand, the documentation also states the following
<begin excerpt>
Garbage collection simplifies memory management and makes it easier to
ensure thread and exception safety. It also avoids common problems
such as retain cycles, and simplifies some code patterns (such as
accessor methods in Cocoa). Together these make applications more
robust.
<end>
Which, of course is also completely true !
Joan Lluch_______________________________________________
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