🚀 go-pugleaf

In article <43qddkINNpti@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

> Yup. Even the implementation of malloc() given in the K&R book is
> sufficient for most needs (though it doesn't use very efficient
> ways for searching for bree blocks). It's far better than some
> contorted scheme involving double indirection.

Depending on what you want to do.  Malloc/free is one heck of a bottleneck
in a lot of applications.

> Could you cite a reference as to where to find an example of such
> an allocation pattern?

A compiler.  Pick up a copy of the lcc book:  A Retargetable C Compiler:
Design And Implementation by Chris Fraser and Dave Hanson (ISBN
0-8053-1670-1).  They have a whole chapter on storage management and the
benefits of arenas for this type of work (basically, it is a lot faster,
uses less memory, and has fewer memory leaks, if your pattern of memory
allocations matches that found in doing compilation).  FYI:  lcc is a
compiler designed for Unix systems, not Macs (as if that makes any
difference, but it might to you), with design goals of being fast and
portable.

> I suspect that in the long run it would be easier to fix an application's
> allocation pattern, should the need arise, than to force yourself to
> complicate _every_ application with nonsense like memory handles and
> double dereferencing.

Bull.  That would require rethinking the entire implementation of an app. 
More likely than not you'll end up managing all the memory yourself.  If I
had to do that in almost single app that I wrote, I'd much rather have the
system do it for me.  Apple claimed it was necessary, and it is easily
proven that in reality, on real Macs running real apps, it was.  Real
applications do compactions and purging when all else fails, and all else
fails often enough to justify the added complexity.
> 
> I think the original Mac designers should have stuck to pixel pushing,
> and hired outside help to do the internals. I suspect that the 
> NIH (Not Invented Here) syndrome had a lot to do with it.

No.  Unlike you, they had practical problems to solve.  You stating that
it wasn't a problem doesn't make it so.  You *still* haven't posted a
solution to what to do if the heap is so fragmented that you can't satisfy
an allocation request, other than quitting the app or buying more
hardware.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799