🚀 go-pugleaf

Here's my $0.02 on handles vs other memory management schemes:

As a longtime Mac programmer, I have to agree that handles are an
inefficient way to deal with memory issues on Modern CPUs. However, I
think the inefficiency is being overstated by many posters. 

IMHO, there is no question that a scheme that uses the MMU to map
allocated blocks of memory to physical locations, thus allowing the
physical location of a block to move but leaving it's virtual address
intact (and thus the pointers to that address intact) is superior.
Essentially this is an implementation of "handles" in hardware, using
virtual memory.

Let's not forget why Apple choose handles in the first place: They had a
128K machine with software that needed lots of resources. In such a
cramped environment that ability to compact the heap and squeeze out the
last little bit of memory reuse was very important. Also there was no MMU
on the 68000 to implement a virtual memory based memory manager.

In addition, the main ineffeciency comes in requiring the programmer to
think a bit more about memory management in writing code. In general, it's
possible to move the handle locking, heap compaction, and other slowdowns
outside of loops and into places where it is not a significant problem.
Let's not forget that pointers are readily available as well, as is
malloc() and new() for those writing in C or C++. If you think that
handles are inefficient, there is no requirement that they be used.

Finally, IMHO, the Mac OS is not condemned to use handles forever. Apple
has successfully managed a transition to new APIs for a particular subset
of the MacOS several times, and while it will add bloat to the OS to
maintain backward compatability, it's still workable.

In short, the memory management on the Mac made compromises to deal with
historical constraints, but other OS's have made compromises as well. At
the present time, the memory management on the Mac works reasonably well
for me as a user and the rest of the OS (GUI, system config, ease of
adding peripherials, etc..) don't make as many compromises as other OSs.

It's the total experience of using an OS that leads me to choose it over
another, not just a single element of it. Particularly when that element
can be largely handled though appropriate programming techniques.

Hope this all makes sense :-)
Ed Zavada

---------------------------------------------------------------------
Ed Zavada                                          Radford University
ezavada@runet.edu                             Environmental Geography
http://www.cs.runet.edu/~ezavada/                  & Computer Science
---------------------------------------------------------------------
    "An eye for an eye leaves the whole world blind." - M. Gandhi
---------------------------------------------------------------------