Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ll-xn!mit-eddie!husc6!linus!philabs!phri!marob!daveh
From: daveh@marob.MASA.COM (Dave Hammond)
Newsgroups: comp.lang.c
Subject: Memory allocation techniques
Message-ID: <415@marob.MASA.COM>
Date: 14 Sep 88 16:09:25 GMT
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC  New York City
Lines: 25

A popular PD program performs its own memory management, satisfying
memory requests from its heap, unless the request exceeds the current
heap size.  At that point additional core is allocated to satisfy the
oversized requirement.

In earlier versions, memory was allocated using sbrk(), and all subsequently
free'd space was returned to the heap. I notice a more recent version is
using malloc() to allocate its memory and only pooling larger chunks of
free'd memory (chunks smaller than 1K are pointedly trashed -- the code calls
them `Wasted').

Questions:

(1) Why the switch from sbrk() to malloc()?  Speed ?  Portability ?
    Dependability ?  I would think adding heap management on top of
    malloc would render malloc's own heap management useless.

(2) Why `waste' smaller chunks?  Since the code uses a first-fit algorythm,
    is this a trade-off between the time spent weeding through smaller chunks
    and the core wasted by the trashed chunks ?

Dave Hammond
  UUCP: uunet!masa.com!{dsix2,marob}!daveh
DOMAIN: dsix2!daveh@masa.com
----------------------------------------------------------------------------