delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/28/10:24:27

Date: Tue, 28 Jan 1997 17:13:00 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
cc: DJGPP AT delorie DOT com
Subject: Re: A misfeature re malloc() and new
In-Reply-To: <A799BD7734@fs2.mt.umist.ac.uk>
Message-ID: <Pine.SUN.3.91.970128170853.11810I-100000@is>
MIME-Version: 1.0

On Tue, 28 Jan 1997, A.Appleyard wrote:

>   If the PC has plenty of RAM, no trouble occurs. If it is e.g. a laptop with
> only about 5 meg of RAM, after malloc()'ing a megabyte block and several
> blocks in the range of 10000 to 80000 bytes, it starts to `thrash' due to
> excessive copying portions of heap between RAM and disk, and if also the hard
> disk is nearly full, symptoms of running out of heap storage start to occur.
> 
>   Would it be safe to free the 1 megabyte block by breaking it up into smaller
> more useful blocks like this, instead of calling free() on it?:-

The only way to be sure (IMHO) is to write a test program that will:

	(1) exhibit the bug with the stock version of malloc/free.
	(2) behave better with your version of free.

There should be no problem to simulate low amount of physical/virtual
memory on any machine (the details depend on the memory manager and the
DPMI host that you are using). 

- Raw text -


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