Re: Heap fragmentation (2nd attempt)
- From: CBFalconer <cbfalconer@xxxxxxxxx>
- Date: Tue, 25 Apr 2006 13:32:38 -0400
Thomas Ruschival wrote:
unfortunately I am still trying to write a sample code that badly
fragments the heap and measure the time it take to allocate memory.
But this heap does not fragment, ant the time to allocate memory
does not increase. I don't know why. I tried different orders of
malloc() free() but I can't measure any runtime differences. In
contrary, the first mallocs on an unused heap take longer and later
after some 1000 malloc/free actions the time used stabilizes on a
lower value. if I then after some time free all my allocated
objects and then start reallocating, time goes up for the first
1000 allocs and drops to the old value. I don't know why.
either I am measureing the wrong stuff or the heap in linux 2.6
with glibc does not fragment for any obscure reason.....
Can anyone tell me where the flaw in my model is?
below is the whole application code (tabsize 4), some parts are
commented out for testing diffent patterns. please play around a
bit and tell me what is wrong - if you can show fragmentation in
any combination of free()/malloc() runs please tell me how!
To start with, your code does not survive transmission as a usenet
article because lines are overlong (should be limited to about 65
chars) and it uses // comments. These do not survive line wraps,
so nobody is going to try to untangle the mess. It also uses
non-standard headers, such as <sys/time.h>, which are unknown
quantities to most readers here.
Secondly, heap fragmentation depends on the malloc package much
more than the sequence of calls. A good package will be relatively
impervious to the call sequence. The place you should be looking
is the source code to your own malloc package.
One of the biggest delays in many packages is the O(N*N) timing of
the free operation, where N is the number of blocks assigned. This
can be reduced to O(N) by making the actual free O(1). It has
nothing to do with fragmentation. For an example of a malloc
package that handles this (for DJGPP, and probably a large class of
*IX based systems also) see my nmalloc package, available at:
<http://cbfalconer.home.att.net/nmalloc.zip>
Remember, the actual malloc package cannot be portable by its very
nature, which is why it is supplied by the system. The nmalloc
package includes test drivers which can assign and free many random
sizes, and allows you take random snapshots of the result. The
guarded debuggery is written to be specific to gcc, but if you
remove that the result should still be useful.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
.
- Follow-Ups:
- Re: Heap fragmentation (2nd attempt)
- From: Thomas Ruschival
- Re: Heap fragmentation (2nd attempt)
- References:
- Heap fragmentation (2nd attempt)
- From: Thomas Ruschival
- Heap fragmentation (2nd attempt)
- Prev by Date: Re: TFT Controller + Ethernet
- Next by Date: Re: some example
- Previous by thread: Heap fragmentation (2nd attempt)
- Next by thread: Re: Heap fragmentation (2nd attempt)
- Index(es):
Relevant Pages
|
|
