[comp.lang.c] Memory allocation techniques

daveh@marob.MASA.COM (Dave Hammond) (09/14/88)

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
----------------------------------------------------------------------------

gwyn@smoke.ARPA (Doug Gwyn ) (09/16/88)

In article <415@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>(1) Why the switch from sbrk() to malloc()?

The most likely reason is that C library routines (and others) may very
well call malloc(), which moves the program break, and the application's
attempt to totally control everything in the heap runs amok at that
point.

>(2) Why `waste' smaller chunks?

Probably it was an attempt to reduce fragmentation problems.

henry@utzoo.uucp (Henry Spencer) (09/18/88)

In article <415@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>(1) Why the switch from sbrk() to malloc()?  Speed ?  Portability ?
>    Dependability ?  ...

Unlikely to be speed; probably a combination of portability and dependability.
The former because the interface to sbrk gets strange on machines which have
strange memory structures, while malloc can hide the gory details.  The
latter because it's increasingly common for library functions to use malloc,
which can royally foul up a program that uses sbrk and assumes it has sole
control of it.
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu