Is there a way to determine the amount of heap remaining on a given processor at runtime? gcc has mstats() that could be used to do this, but that function doesn't seem to be available in this version of the compiler. There is a tempting reentrant version defined in a header (_mstats_r), but this doesn't seem to exist either.
Any ideas how to do this, or if it's even possible?
Thanks,
Paul
Determining heap remaining at runtime
-
- Experienced Member
- Posts: 64
- Joined: Tue Oct 05, 2010 7:33 pm
-
- Experienced Member
- Posts: 82
- Joined: Fri Nov 05, 2010 2:59 pm
Presumably you are referring to a heap as implemented by malloc() and friends. I've not used it, but poking about it seems thatPaolomio wrote:Is there a way to determine the amount of heap remaining on a given processor at runtime? gcc has mstats() that could be used to do this, but that function doesn't seem to be available in this version of the compiler. There is a tempting reentrant version defined in a header (_mstats_r), but this doesn't seem to exist either.
Any ideas how to do this, or if it's even possible?
Thanks,
Paul
Code: Select all
struct mallinfo mallinfo (void);
Maybe you need to try #include <malloc.h> too?
Incidentally, is the XMOS malloc implemetation well-behaved on out-of-memory i.e. returning a NULL pointer on failure? I've not tested it yet.
What are you going to use the information of free memory for? is it just a help for a developer knowing how much headroom is available when developing programs or is it for some magic algorithm that tries to share out dynamic memory in some sort of multicore mega-pool scheme? Generally you just want to know if your allocation request succeeded or failed.
Hope this helps.
Max.
-
- Experienced Member
- Posts: 64
- Joined: Tue Oct 05, 2010 7:33 pm
Thanks for this--it's great info. I'll check it out and report back.
No magik here...in the process of running, my code allocates various structures and memory blocks, all based on data coming from ethernet. It would be nice to be able to fail gracefully early in the process of building up these structures and let the user know there isn't enough memory to "perform the requested action", rather than just ignore the request, or worse get down into the middle of creating these structures and run out. If I can see how much is free before I start building up the data structures I can decide beforehand if it's likely to succeed...
Paul
No magik here...in the process of running, my code allocates various structures and memory blocks, all based on data coming from ethernet. It would be nice to be able to fail gracefully early in the process of building up these structures and let the user know there isn't enough memory to "perform the requested action", rather than just ignore the request, or worse get down into the middle of creating these structures and run out. If I can see how much is free before I start building up the data structures I can decide beforehand if it's likely to succeed...
Paul
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
The free heap space does not have to be a contiguous block, that complicates matters, it's not just checking how much space is free, but you also have to check whether it fits in a "hole". And if you want to allocate memory for multiple structures that do not have to be contiguous, the check mechanism somehow has to cache your previous requests (i.e. there is only one block free that fits a 1KB structure. You need to allocate two of them, without caching it will give green light for both checks while there is only room for one).Paolomio wrote:Thanks for this--it's great info. I'll check it out and report back.
No magik here...in the process of running, my code allocates various structures and memory blocks, all based on data coming from ethernet. It would be nice to be able to fail gracefully early in the process of building up these structures and let the user know there isn't enough memory to "perform the requested action", rather than just ignore the request, or worse get down into the middle of creating these structures and run out. If I can see how much is free before I start building up the data structures I can decide beforehand if it's likely to succeed...
Paul
-
- Respected Member
- Posts: 318
- Joined: Tue Dec 15, 2009 12:46 am
The heaps starts after the data / code and grows upwards. The stack starts at the end of memory and grows downwards. If the stack usage of your program is known at compile time a limit will be set on the heap thats prevents it from overlapping with the stack. If this limit is exceeded malloc will return NULL.MaxFlashrom wrote:Incidentally, is the XMOS malloc implemetation well-behaved on out-of-memory i.e. returning a NULL pointer on failure? I've not tested it yet.
If the stack size of your program is unknown at compile time then it is possible for end of the heap to be extended past the stack, resulting in memory corruption.
-
- Experienced Member
- Posts: 64
- Joined: Tue Oct 05, 2010 7:33 pm
@richard,
Thanks, that's helpful...
I have tried using mallinfo() to try and determine how much heap is available, but this function returns unexpected (read: not very useful) values. It only seems to update the arena and uordblks fields, all others are zero. Is this by design or am I doing something wrong?
Thanks,
Paul
Thanks, that's helpful...
I have tried using mallinfo() to try and determine how much heap is available, but this function returns unexpected (read: not very useful) values. It only seems to update the arena and uordblks fields, all others are zero. Is this by design or am I doing something wrong?
Thanks,
Paul