This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: malloc
- To: ecos-discuss at sources dot redhat dot com
- Subject: Re: [ECOS] malloc
- From: "Lewin A.R.W. Edwards" <larwe at larwe dot com>
- Date: Sat, 03 Feb 2001 10:12:03 -0500
- References: <4.3.2.7.2.20010201142717.00ab96e0@larwe.com>
Hi Jonathan,
> > I'm using the Cirrus 7212 and malloc seems to be very random in behavior -
>
>I found some problems in the memory allocator a while back and fixed them.
>Alas I also redesigned the memory allocation system at the same time, so it
I'm happy to hear that there _is_ a known problem with the version I've
got, because it indicates that I probably don't have some deeper lurking
problem :)
I have written my own "dirty memory manager" which sounds rather like how
you described the old eCos manager, except that my implementation does not
support realloc or free. It has a fixed heap size (static array).
When I am using dynamic allocation, I don't want the structures to have any
permanent lifespan. There are only two parts of my code that use dynamic
allocation, because they need to create an indeterminate (known only at
runtime) number of structures of an indeterminate size. I know roughly what
the aggregate size of these structures will be, but not how the space will
be distributed. The structures exist while I am decoding a particular data
stream, and have no meaning thereafter, so my memory manager essentially
only works with one process - you call a "reset" function before you use
it, and then allocate all you want. When you're finished, there is no need
to deallocate anything because the next time the reset function is called,
all sins are forgiven.
It is much, much, much easier for me to do this than to have to worry about
heap fragmentation.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/
"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."