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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to