delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/02/09/02:05:03

Xref: news2.mv.net comp.os.msdos.djgpp:899
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: malloc/free ends up fragmenting dynamic memory?
Date: Tue, 06 Feb 1996 22:52:21 CST
Organization: Rice University, Houston, Texas
Lines: 23
Message-ID: <31183005.sandmann@clio.rice.edu>
References: <DMCyMn DOT G6u AT granite DOT mv DOT net>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> I did not know that. If I recall correctly the reason to select the current
> type of malloc in DJGPP was that it goes well with virtual memory. Is it not
> possible then at least to combine the BSD and GNU (or the Borland) type of
> malloc to get the best of both world: fast virtual memory, which is
> defragmented? Or are these incompatible things?

There is a problem with gnu malloc - its LGPL so you can't write commercial
code with it, so it's not the default in the library.

The problem with malloc() is you need to know what you are going to use
it for, and set the algorithm accordingly.  

In one type of programming I do, NOTHING except a best fit with cleanup/
merging will work without blowing out the virtual size, since the allocation
requests vary over 7 orders of magnitude.  But it calls malloc() relatively
infrequently, so the increased overhead is unnoticeable (compared to the
paging overhead if you get it wrong).

In another type I need, speed is everything, memory usage isn't an issue, so
the bsd like default algorithm works great.

And there are applications in-between.  I suggest if you do a wide range of
programming tasks, you start collecting (or writing) mallocs ...

- Raw text -


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