Determining heap remaining at runtime

[Paolomio]

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

[MaxFlashrom]

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

Presumably you are referring to a heap as implemented by malloc() and friends. I've not used it, but poking about it seems that

Code: Select all

struct mallinfo mallinfo (void); 

found in XMOS/DevelopmentTools/11.2.2/target/include/malloc.h looks promising. This returns a mallinfo struct with a whole lot of information. ANSI C defines malloc to be included via #include <stdlib.h>
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.

[Paolomio]

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

[Bianco]

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

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).

[richard]

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.

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.

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.

[Paolomio]

@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