🚀 go-pugleaf

In article <MLM.95Sep20011239@monaco.cs.brown.edu>,
Moises Lejter <mlm@cs.brown.edu> wrote:
>In article <43nlc8$sll@orion.cybercom.net>, jerry@cybercom.net (Jerry Shekhel) writes:
>
>  Jerry> UNIX systems ignore the problem and let the applications
>  Jerry> worry about their own heap management.  The OS itself
>  Jerry> provides only rudimentary facilities for expanding the heap.
>  Jerry> On the other hand, UNIX provides very robust virtual memory
>  Jerry> capabilities, so most programs can get by using only the
>  Jerry> unsophisticated heap management of malloc() and related
>  Jerry> functions.
>
>I am not sure how fair this statement is to modern versions of UNIX.
>It is true that the OS itself provides rudimentary facilities for
>expanding the heap - just sbrk() to extend heap memory.  However, the

You are also forgeting about memory mapped files and MAP_ANON
regions. (I won't mention SVRx shared memory segments. Oops, just did!).

>standard C library's heap allocation routines (malloc() and friends)
>do try to do a reasonable job in terms or reusing freed blocks,
>compacting contiguous free blocks when convenient.  I will grant you

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.

>it is possible to construct an application whose dynamic memory
>behavior will defeat the strategies in the standard C library, but I
>am not sure that this is commonly a problem...

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

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.

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.

-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?