I have some questions regarding memory allocation and freeing with MQX that I hope someone can help with. Our current application approach is using a lot of malloc and free calls, both of which we have pointed at the corresponding MQX memory functions for system memory (_mem_alloc() and _mem_free() ). How does MQX address memory fragmentation and how well does MQX will keep track of a large number of freed memory holes for reuse on future malloc calls. My understanding is that MQX will track the freed memory areas, and thier size, and use them for future allocations. My questions are:
- Is there a limit to the number of memory areas MQX will track?
- Does MQX look for a “first fit” or “best fit”?
i.e. after freeing 60 bytes, if a malloc needs 10, will it take 10 out of the 60 byte freed area if it is the first memory area checked, or will it search for a better fitting memory hole?
- Does MQX combine adjacent freed memory holes when freeing memory? i
.e. in the example from 2. If the 10 bytes are taken from the freed 60 bytes, leaving a 50 byte freed area, and the 10 bytes are later freed, will it result in 2 memory areas tracked by MQX, one 10 bytes and the other 50 bytes, or will it detect that they are adjacent/contiguous in memory and combine them back into 60 byte area?
- _mem_copy vs memcpy : I do not believe we have overridden the C library memcpy function to use the MQX _mem_cpy function. What problems will this create? Do the MQX memory functions handle size differently to accommodate for alignment or fit, whereas the C library might not?
- Is there a way to get insight into how fragmented the memory is becoming over time?
Suggestions on best ways to accommodate the need for a lot of dynamic memory use across functional areas of the code and across threads? Have considered memory pools / blocks, msq queues - not sure which pros & cons of each will impact things the most.