joel.sherrill at OARcorp.com
Tue Oct 21 20:39:29 UTC 2003
Angelo Fraietta wrote:
> About a year and a half ago, I found that there I was getting memory
> fragmentation, which caused RTEMS to lock up.
> I had a class of about eight bytes in size, and allocated and
> deallocated an object of this class 100 times every second. There was
> only ever two objects active at any one time.
> After about three days, RTEMS locked up and had to be rebooted. I
> overcame this by overloading operators new and delete in the class and
> made a memory manager for the class. I have run it for two weeks
> without a problem now.
I think this was a good solution in your case. It sounds like the C++
equivalent of not really freeing something to the heap and reusing them.
Very close to preallocating a set of objects and having
allocate and deallocate routines which did not touch the heap at all.
I would have thought that instead of locking up, it would have
eventually reused some of those blocks. But if there were other
new/delete's then it might ahve simply failed at some point.
Also did you do free's from interrupt handlers -- that is currently
forbidden. That would have a chance of a weird failure.
> I am bring this up now because I am writing up my thesis and has come to
> Has memory fragmentation been resolved or considered for RTEMS apart
> from partitioning?
Not really. I suspect in your case, the problem is that the heap
is a first fit algorithm while your application might be better
served with a best fit one.
But in general, I think your solution was the appropriate embedded
systems one. You ended up solving not only a fragmentation problem
but probably a performance one as well. It has to be less expensive
computationally to avoid malloc. NOTE: free on RTEMS is deterministic
for the C Program Heap since you can't block waiting on memory from
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users