Message-Id:	<199710311119.WAA10318@mona.lexicon.net.au>
Comments:	Authenticated sender is <sjmachin AT mail DOT lexicon DOT net DOT au>
From:	"John Machin" <sjmachin AT lexicon DOT net DOT au>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Date:	Fri, 31 Oct 1997 22:17:55 +1000
MIME-Version:	1.0
Subject:	Re: malloc()
CC:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
References:	<199710301211 DOT XAA08637 AT mona DOT lexicon DOT net DOT au>
In-reply-to:	<Pine.SUN.3.91.971030163921.5063A-100000@is>

On 30 Oct 97 at 16:42, Eli Zaretskii wrote:
> 
> On Thu, 30 Oct 1997, John Machin wrote:
> 
> > Allocators which don't split/coalesce free blocks can break 
> > down if the program allocates a large number of blocks of size x, 
> > frees them, allocates/frees ditto sizes y,z, etc (where x,y,z etc 
> > belong in different power-of-two buckets) --- unrealistic? No, e.g. 
> > program == text editor, x == average len of source file line, y == 
> > average len of record in data file1,...
> 
> Could you please write a test program along these lines, or find such
> a program written by somebody else?  It would be interesting to compare 
> the two malloc's with such a program.  Thanks.
> 
OK, I've been sucked in now :-)

I plan to extend the program originally supplied by SET, to:

***  allow a variable number of blocks, instead of 1024, as per 
previous message.

*** specify a target amount of memory to fill up e.g. say I have 
16 Mb of real memory, I'd like to be able to say (a) grab 12 MB with 
malloc and then do malloc/free maintaining the used memory at average 
12 Mb , max say 13 Mb --- to test the various mallocs with real 
memory (b) repeat with say average 18 Mb, max 20Mb --- to see how 
they behave when swapping is necessary

*** have various known malloc-busting patterns (like the one I've 
suggested). Every malloc has its worst case ...

One thing we would need to agree on is how to measure wastage. SET 
has made (I think) a valid point: if you allocate 8192 bytes but 
touch only the first 4096 bytes, the second 4096 bytes is just 
address space; it is not mapped to physical RAM, and so is not 
wasted. Is this still the case when swapping happens? If I allocate n 
pages (where n is a large number), and touch only pages 0 and n-1, 
will the swap file be n pages long or two pages long?

The only malloc testing code that I've found on the net so far is 
obviously Unix- & portability-oriented. It goes something like this:
	p0 = sbrk(0);
        malloc/free madly ..
        p1 = sbrk(0);
	bytes_grabbed = p1 - p0;
        bytes_actually_required = amount_malloced - amount_freed;
	bytes_wasted = bytes_grabbed - bytes_actually_required;
In other words basically the same as us, just using sbrk() instead of 
_go32_dpmi_...

Comments please ...





John Machin
1/27 Auburn Grove
Hawthorn East, VIC 3123, Australia
Phone: +61-3-98130561

- Raw text -