Re: Memory Management Mismanaged
Re: Memory Management Mismanaged
- Subject: Re: Memory Management Mismanaged
- From: publiclook <email@hidden>
- Date: Wed, 7 May 2003 23:07:33 -0400
Below is a long explanation because is was requested:
On Wednesday, May 7, 2003, at 09:53 PM, Dustin Voss wrote:
On Wednesday, May 7, 2003, at 04:46 AM, lbland wrote:
On Wednesday, May 7, 2003, at 06:59 AM, Pete Yandell wrote:
Seriously though, grafting full garbage collection onto objective-C
would clearly be pretty close to impossible
just for fun...
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Garbage-
Collection.html#Garbage Collection
So, wait, this works? Then why the heck are we all using
retain/release?!
- Mark and sweep garbage collection does not work well with distributed
objects. Reference counting does.
- Mark and sweep garbage collection is notorious for negatively
impacting interactive application usage. e.g. it adds unpredictable
latency to user interaction.
- Mark and sweep garbage collection typically requires a larger working
set in RAM. Will you need still more ram ?
- Using Mark and sweep garbage collection with the millions of lines of
existing C code often requires detailed knowledge of how to selectively
enable, disable, and tune the collector collector behavior. Such
knowledge is IMHO more arcane than using Cocoa's reference counting.
- Mark and sweep garbage collection is not be used for memory and other
resources allocated from sources other than heap. e.g. you still may
have to learn reference counting to know when you can reuse graphics
card texture memory or relinquish control of a socket or communicate
over a language bridge to another language or use distributed objects
or use COM or use MFC CString instances.
- Reference counting is a valuable tool in the toolbox just like
hashing, data structures, object oriented decomposition, etc.
Demanding automatic garbage collection just because you don't want to
learn how to use a powerful general purpose tool is like doing wood
sculpture with a screw driver because you don't want to learn how to
use or sharpen a chisel.
- Mark and sweep garbage collection is inappropriate in many classes of
application including graphics, animation, CD burning, etc. Basically,
Mark and sweep garbage collection is inappropriate in most real-time
applications. In fact, such applications typically don't dynamically
allocate memory at all during critical operations because malloc and
free are also inappropriate. The difference is that you have to know
how to selectively disable and reschedule mark and sweep garbage
collection for such applications. That is typically much more
difficult than just not calling +alloc, -copy, -release, malloc(),
free() or whatever.
Java and Smalltalk both have much more sophisticated and capable
garbage collectors than the Boehm-Demers-Weiser conservative garbage
collector and have built in language support unlike C. You will read
about lots of issues and problems in the Java and Smalltalk groups.
Now, having given all these reasons for why we are not all using mark
and sweep garbage collection, let me say that pretty much any
application that would have been written in Cobol 20 years ago is
suitable for use with mark and sweep garbage collection today. That is
not meant to be flippant. Perhaps 90 percent of all software
applications have no latency requirements (other than mere user
aesthetics), no real-time requirements, don't use distributed objects,
don't call legacy C libraries that are incompatible with garbage
collection (perhaps because they already implement their own), don't
use non-heap based resources, don't mask pointers by for example
casting them back and forth between non-pointer types (oops, Carbon and
CoreFoundation are full of that), don't use pointers returned from
system calls such as shared memory (can't garbage collect the
kernel...), don't implement animation, are not device drivers etc.
There are a lot of databases applications and desktop calculators out
there...
If you want to write graphical games, device drivers, highly responsive
GUI applications, applications that use shared memory, applications
that use distributed objects, openGL applications, applications that
use existing C libraries that are incompatible with automatic garbage
collection, high performance screen savers, and similar things, you
won't be using the Boehm-Demers-Weiser conservative garbage collector
any time soon.
If Cocoa required the use of the Boehm-Demers-Weiser conservative
garbage collector, Cocoa would be excluding itself from use in many
types of application. Heck, NeXT used to implement device drivers with
Objective-C... Basically, if Cocoa used the Boehm-Demers-Weiser
conservative garbage collector, Cocoa would be limited to the
application domains served by Java. That is a big domain, but cocoa's
existing domain is even bigger (in theory), and IMHO Cocoa's reference
counting is easier to use than knowing when to use or not use weak
references with Boehm-Demers-Weiser.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.