5 ms·

This is why some embedded systems don't do malloc (IIRC...been a while since I've read much about those).

by davidw 5y ago

edwinbalani 5y ago
That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification. If you still need dynamic allocation, you might choose to have a custom allocator working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed).
- edwinbalani 5y ago
  (All that said, embedded systems sometimes don't have virtual memory, so the original problem stated in the link is just not a thing...) > working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed) And I should add to this that you probably want to access all of the pool/arena to do setup, or just ensure it's physically allocated if you are running in a virtual memory space. This is something that is reasonable at setup time, though.
- SV_BubbleTime 5y ago
  All good stuff. I’m working on a project now and trying my best to make it MISRA compatible because FreeRTOS did the same. You don’t use malloc() but rather pvPortMalloc() which pulls from an already allocated pool. Their HEAP4 system tries to keep the chunks organized. So far I’ve been very happy with it.
stefan_ 5y ago
Embedded systems (the ones where you would disallow malloc) don't generally have virtual memory by virtue of having no MMU, so on those you can't do overcommitment since there is no page fault mechanism. No, the reason is simply that by statically allocating all memory you can avoid entire classes of program faults and bugs. There are no memory leaks and you don't need to solve the NP-complete problem of "is there an execution path where a dynamic memory allocation will fail". Keep in mind that it is not just about the total amount of dynamically allocated memory, but also the order of allocations (and frees).
tjoff 5y ago
I wouldn't say this is the reason. Embedded systems typically don't have virtual memory to start. I would expect (but verify) a malloc implementation on embedded to return null if it can't satisfy the allocation. But even with that assumption malloc in embedded is often a bad idea. You need to plan for worst case anyway and you can not afford memory fragmentation.
aidenn0 5y ago
Aside from the fact that overcommit usually doesn't apply to embedded systems, malloc() is fine; its free() that is the problem.
agumonkey 5y ago
I'd love to see how people design software with fully static memory (and limited one at that)
- asgeir 5y ago
  You can find a number of technical deep-dives for classic video game consoles where people have had do deal with very limited resources. This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE https://www.youtube.com/watch?v=tfAnxaWiSeE
  - agumonkey 5y ago
    cool, I should dig about that sub topic too.

This is why some embedded systems don't do malloc (IIRC...been a while since I've read much about those).

by davidw 5y ago

This is why some embedded systems don't do malloc (IIRC...been a while since I've read much about those).

That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification. If you still need dynamic allocation, you might choose to have a custom allocator working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed).

edwinbalani 5y ago
(All that said, embedded systems sometimes don't have virtual memory, so the original problem stated in the link is just not a thing...) > working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed) And I should add to this that you probably want to access all of the pool/arena to do setup, or just ensure it's physically allocated if you are running in a virtual memory space. This is something that is reasonable at setup time, though.
SV_BubbleTime 5y ago
All good stuff. I’m working on a project now and trying my best to make it MISRA compatible because FreeRTOS did the same. You don’t use malloc() but rather pvPortMalloc() which pulls from an already allocated pool. Their HEAP4 system tries to keep the chunks organized. So far I’ve been very happy with it.

stefan_ 5y ago

Embedded systems (the ones where you would disallow malloc) don't generally have virtual memory by virtue of having no MMU, so on those you can't do overcommitment since there is no page fault mechanism. No, the reason is simply that by statically allocating all memory you can avoid entire classes of program faults and bugs. There are no memory leaks and you don't need to solve the NP-complete problem of "is there an execution path where a dynamic memory allocation will fail". Keep in mind that it is not just about the total amount of dynamically allocated memory, but also the order of allocations (and frees).

tjoff 5y ago

I wouldn't say this is the reason. Embedded systems typically don't have virtual memory to start. I would expect (but verify) a malloc implementation on embedded to return null if it can't satisfy the allocation. But even with that assumption malloc in embedded is often a bad idea. You need to plan for worst case anyway and you can not afford memory fragmentation.

aidenn0 5y ago

Aside from the fact that overcommit usually doesn't apply to embedded systems, malloc() is fine; its free() that is the problem.

agumonkey 5y ago

I'd love to see how people design software with fully static memory (and limited one at that)

asgeir 5y ago
You can find a number of technical deep-dives for classic video game consoles where people have had do deal with very limited resources. This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE https://www.youtube.com/watch?v=tfAnxaWiSeE
- agumonkey 5y ago
  cool, I should dig about that sub topic too.