Meaning of value returned by system_get_free_heap_size

[dkinzer]

Does the value returned by system_get_free_heap_size() represent the total size of the unallocated heap blocks, the size of the largest unallocated block, the size of the largest allocation request that would succeed, or something else?

Also, is there an API for walking the heap or for verifying the heap integrity?

[eriksl]

In my experience it comes quite close to what I'd expect: the amount of bytes free for "malloc" and stack size. You start with about 80 kbytes of dram (as opposed to 32 kbytes of iram), then all variables are allocated, maybe some complementary storage, I guess some storage for the wlan code. The rest is heap. Malloc (or os_malloc if you like) takes storage from the bottom of the area, while the stack grows from the top downwards. At least that is how it works on almost all simple computer systems. The amount of space in the heap not allocated is the free space in dram. It can be used for expanding the stack or for allocating more heap (malloc). Be careful with putting variables on the stack ("auto" variables, as opposed to static or malloced pointers), it the objects are big, they can overwrite the top of the allocated heap and v.v.

Anyway, the function gives about 26 k free, which is about what I'd expect. If I add a variable of 1024k in size (not on the stack, but static), I can see the free heap space shrink to 25 k, so very predictable. Likewise with malloc.

[dkinzer]

I did an experiment with allocating some blocks and observing the effect on the value returned by system_get_free_heap_size(). My conclusion is that the value represents the total size of all unallocated blocks (including a 16-byte block management overhead). Here is the data:

o initial free space (value returned by system_get_free_heap_size) is 47536
o allocate 1000 bytes, free space is 46520 (apparently a 16-byte allocation overhead)
o allocate 1000 bytes, free space is 45504
o free the first 1000 byte allocation, free space is 46520 (but space is fragmented)
o attempt to allocate 45620 fails
o free the second 1000 byte allocate, free space is 47536
o attempt to allocate 47536 bytes fails
o attempt to allocate 47532 bytes fails
o attempt to allocate 47528 bytes fails
o attempt to allocate 47524 bytes fails
o attempt to allocate 47520 bytes succeeds

[dkinzer]

Additional data:

o allocating 256 bytes reduces the heap space by 272 bytes (16 bytes overhead)
o allocating 257 through 264 bytes reduces the heap space by 280 bytes (23 to 16 bytes overhead)
o allocating 265 through 272 bytes reduces the heap space by 288 bytes (23 to 16 bytes overhead)

The conclusion that I draw from this data is that the allocation request is rounded up, if necessary, to be an integral multiple of 8 and then 16 bytes is added for tracking information.

I'm a bit surprised at this. I would have expected the request to be rounded up to an integral multiple of 4. Further, I expected to see at most 8 bytes of tracking overhead - 4 for the block size and 4 for a link to the next element in the list. I have written allocators that had overhead for only the block size (the "next element" link being stored in the data area of the freed block). Perhaps they're keeping all blocks, whether allocated or free, on a doubly linked list and storing the size, too.