X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID: <3C7919F2.96FFA97D@yahoo.com>
Date: Sun, 24 Feb 2002 11:50:58 -0500
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Malloc/free DJGPP code
References: <10202201713 DOT AA23034 AT clio DOT rice DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> 
> > To those interested in optimizing the performance of malloc, please
> > remember that malloc is used in a lot of different ways, and it is
> > unwise to concentrate on one aspect of its performance, because
> > some other application may suffer.
> 
> I'm painfully aware of this.  I've written 3 different malloc packages
> in the past - each which was optimized for a particular applications
> need (and was layered in the application to fix problems with memory
> allocation).

And I have done at least as many equivalents for different
languages and/or applications. Some were intrinsically highly
inefficient, because the objective was to strictly limit the time
spent in any one call.  Some of these were effectively garbage
collectors.

I have come to a point in my rework of malloc (which will
eventually be available for evaluation and inclusion or not as
desired) where I have to make a subtly major revision. The problem
is that I have not been able to capture good regression tests,
because the output depends on the behaviour of sbrk, and the
result will be more detailed perusing of debug outputs.

This could all be cured by a semi-portable implementation of, say,
"fakesbrk" which will return a repeatable set of addresses under
the same circumstances.  It might actually malloc a large block
which contains those addresses to be faked.  But how can it ensure
that a certain range is available to any degree of certainty, or
even of probability? This might in turn require a fake dpsmi
implementation, which is getting ridiculous.  The addresses
returned have to be usable.

Any ideas?  So far much more effort has gone into providing clear
debug output than in actually programming the beast, but I believe
the result is worthwhile.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:uce AT ftc DOT gov  (for spambots to harvest)