There are a lot of different strategies for allocating memory. Programming languages like Python or Java request their memory from the heap at runtime. Of course, C or C++ also has a heap but prefers the stack. But these are by far not so only strategies for allocating memory. You can preallocate memory at the program’s start time as a fixed block or a pool of memory blocks. This preallocated memory can afterward be used at the runtime of your program. But the critical question is: What are the pros and cons of the various strategies to allocate memory?<\/p>\n
<\/p>\n
At first, I want to present four typical memory strategies.<\/p>\n
Dynamic allocation, also called variable allocation, is known to each programmer. Operations like new <\/span>in C++ or malloc <\/span>in C request the memory when needed. On the contrary, calls like delete <\/span>in C++ or free <\/span>in C release the memory when not needed anymore.<\/p>\n The subtle difference in the implementation is whether the memory will be automatically released. Languages like Java or Python know general garbage collection, C++ or C is contrary not. (Only for clarification: That is not totally true because we have the Boehm<\/a>–Demers<\/a>–Weiser<\/a> conservative garbage collector that <\/span>can be used as a garbage collecting replacement for C malloc<\/tt> or C++ new<\/tt>. Here are the details: https:\/\/www.hboehm.info\/gc\/<\/a>).<\/p>\n Dynamic memory management has a lot of pros. You can automatically adjust the memory management to your needs. The cons are that there is always the danger of memory fragmentation. In addition, a memory allocation can fail or take too much time. Therefore, many reasons speak against dynamic memory allocation in highly safety-critical software that requires deterministic timing behavior.<\/p>\n Smart Pointers in C++ manage their dynamic memory by objects on the stack.<\/p>\n Stack allocation is also called memory discard. The critical idea of stack allocation is that the objects are created in a temporary scope and are immediately freed if the objects go out of scope. Therefore, the C++ runtime takes care of the lifetime of the objects. The scope is typically areas like functions, objects, or loops. But you can also create artificial scopes with curly braces. <\/p>\n <\/p>\n A beautiful example of stack allocation is the smart pointers std::unique_ptr<\/span> and std::shared_ptr.<\/span> Both are created on the stack to care for objects created on the heap.<\/p>\n But what are the benefits of stack allocation? At first, memory management is easy because the C++ runtime manages it automatically. In addition, the timing behavior of memory allocation on the stack is deterministic. But there is a big disadvantage. On the one hand, the stack is smaller than the heap; on the other hand, the objects should often outlive their scope, and C++ supports no dynamic memory allocation on the stack.<\/p>\n Most of the time, static allocation is called fixed allocation. The key idea is that at runtime, required memory will be requested at the start time and released at the shutdown time of the program. The general assumption is that you can precalculate the memory requirements at runtime.<\/p>\n <\/p>\n Objects a and b in this example are constructed in the preallocated memory of memory <\/span>and memory2<\/span>.<\/p>\n What are the pros and cons of static memory allocation? In hard real-time driven applications, in which the timing behavior of dynamic memory is no option, static allocation is often used. In addition, the fragmentation of memory is minimal. But of course, there are pros and cons. Often it is not possible to precalculate the application’s memory requirements upfront. Sometimes your application requires extraordinary memory at runtime. That may be an argument against static memory allocation. Of course, the start time of your program is longer.<\/p>\n Memory pool, also called pooled allocation, combines the predictability of static memory allocation with the flexibility of dynamic memory allocation. Similar to the static allocation, you request the memory at the start time of your program. In opposite to the static allocation, you request a pool of objects. At runtime, the application uses this pool of objects and returns them to the pool. If you have more the one typical size of object, it will make sense to create more than one memory pool.<\/p>\n What are the pros and cons? The pros are quite similar to the pros of static memory allocation. On the one hand, there is no memory fragmentation; on the other hand, you have predictable timing behavior of the memory allocation and deallocation. But there is one significant advantage of memory pool allocation to static allocation. You have more flexibility. This is for two reasons. The pools can have different sizes, and you can return memory to the pool. The cons of memory pools are that this technique is quite challenging to implement.<\/p>\n int<\/span>* myHeapInt= new<\/span> int<\/span>(5);\n delete<\/span> myHeapInt;\n\n<\/pre>\n<\/div>\nStack allocation<\/h3>\n
{\n int<\/span> myStackInt(5);\n}\n<\/pre>\n<\/div>\nStatic allocation<\/h3>\n
char<\/span>* memory= new<\/span> char<\/span>[sizeof<\/span>(Account)];\nAccount* a= new<\/span>(memory) Account;\n\nchar<\/span>* memory2= new<\/span> char<\/span>[5*sizeof<\/span>(Account)];\nAccount* b= new<\/span>(memory2) Account[5];\n<\/pre>\n<\/div>\nMemory pool<\/h3>\n
What’s next?<\/h2>\n