delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/05/12/00:20:27

Date: Wed, 11 May 94 23:30:13 -0400
From: dj AT ctron DOT com (DJ Delorie)
To: jthomas AT cs DOT uhh DOT hawaii DOT edu
Cc: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp, DJGPP AT sun DOT soe DOT clarkson DOT edu
Subject: Re: malloc

The way it works (in djgpp, at least), in a nutshell, is this:

* The operating system allocates a single block of memory to the
application.  The application can change the size of this block, but
cannot obtain another.  This block is recovered by the OS when the
application exits.

* sbrk() and brk() are direct OS calls that ask to change the size of
the application's memory block.  This limit is called the "break"
(since programs break if you access beyond it :-).  Any application
*can* lower the break and return memory to the system (lisp can do
this efficiently) but the C memory model just doesn't make this
practical (or possible, in most cases).

* when malloc() needs more memory than it has, it asks the OS to grow
the application's block (usually in efficiently large chunks), and
internally divvies the extra memory up for the functions that call it.

* when you free() memory, malloc will just put it on an internal list
of available memory in case it needs to get re-used later (instead of
growing the application's memory block).

DJ


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019