Message-Id: <199710311119.WAA10318@mona.lexicon.net.au> Comments: Authenticated sender is From: "John Machin" To: Eli Zaretskii , djgpp AT delorie DOT com Date: Fri, 31 Oct 1997 22:17:55 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: malloc() CC: "Salvador Eduardo Tropea (SET)" References: <199710301211 DOT XAA08637 AT mona DOT lexicon DOT net DOT au> In-reply-to: Precedence: bulk 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