Dynamic Linux Memory
In this article we will take look at how the heap works on the Linux operating system. This includes structure, allocation, functions, clean-up and other important details. Feel free to ask questions in comments as the topics ahead are rather complex compared to that of stack-based memory.
We will go through how dynamic memory differs from stack memory and analyse the aspects of its management.
Memory – The Heap
When memory space is needed and that size is fixed by the programmer, the stack may be the best choice to hold that data. You commonly see functions making use of the stack segment to pass constant sized variables to other called functions, often with the goal of receiving a return value of some sort. Once a function is complete, control is returned to the calling function. Functions that are given memory on the stack have a finite lifetime and use a Last in First out (LIFO) manner of handling itself. For example, the main () function is allocated memory on the stack. As functions are called from main (), the memory is allocated on the stack on top of main () and grows from higher memory addressing towards lower memory addressing. Thus when you are allocating space on the stack, you are actually subtracting the desired amount of space from the ESP register as it grows. The stack has a benefit in where it automatically cleans up after itself once a function is complete. This is not the same as with a heap.
When the data is of a variable amount, must be accessible by multiple functions, is large and/or does not necessarily have a finite lifetime, the heap may be the best location for that data. During program runtime, the loader loads segments of data into memory such as the code segment and data segment. Also created at program runtime are the stack and heap segments. Global and static variables such as that in the .data and .bss segments are often placed after the code segment and before the heap, although it can be argued that these sections are in fact part of the process heap. The kernel requests memory using system calls such as sbrk() and mmap(), These calls allocate a large block of data and do not make the most efficient use of memory, thus we want a way to manage memory more efficiently using something that sits between the program and the system call. In the C programming library there are a group of functions under malloc() that divide up the memory allocated by the system calls brkf), sbrkf) or mmap() into chunks that are more efficient and manageable.
With the heap, allocated memory is not automatically cleaned up as with the stack. The stack has a calling convention that automatically takes care of popping values off the stack and returning control to the calling function. The heap, on the other hand, requires the programmer to call a function to free the memory allocated. Failure to free the memory on the heap can result in problems including memory leakage, resource exhaustion, and fragmentation. When a user opens up a web browser, the developers of the browser have no way of knowing how many tabs the user will open, what types of pages will be visited, how much memory space is required for each site, etc. . It is this that makes the heap a more desirable location for the data than the stack.
In this article we will take look at how the heap works on the Linux operating system. This includes structure, allocation, functions, clean-up and other important details. Feel free to ask questions in comments as the topics ahead are rather complex compared to that of stack-based memory.We will go through how dynamic memory differs from stack memory and analyse the aspects of its management.
Memory – The Heap
When memory space is needed and that size is fixed by the programmer, the stack may be the best choice to hold that data. You commonly see functions making use of the stack segment to pass constant sized variables to other called functions, often with the goal of receiving a return value of some sort. Once a function is complete, control is returned to the calling function. Functions that are given memory on the stack have a finite lifetime and use a Last in First out (LIFO) manner of handling itself. For example, the main () function is allocated memory on the stack. As functions are called from main (), the memory is allocated on the stack on top of main () and grows from higher memory addressing towards lower memory addressing. Thus when you are allocating space on the stack, you are actually subtracting the desired amount of space from the ESP register as it grows. The stack has a benefit in where it automatically cleans up after itself once a function is complete. This is not the same as with a heap.
When the data is of a variable amount, must be accessible by multiple functions, is large and/or does not necessarily have a finite lifetime, the heap may be the best location for that data. During program runtime, the loader loads segments of data into memory such as the code segment and data segment. Also created at program runtime are the stack and heap segments. Global and static variables such as that in the .data and .bss segments are often placed after the code segment and before the heap, although it can be argued that these sections are in fact part of the process heap. The kernel requests memory using system calls such as sbrk() and mmap(), These calls allocate a large block of data and do not make the most efficient use of memory, thus we want a way to manage memory more efficiently using something that sits between the program and the system call. In the C programming library there are a group of functions under malloc() that divide up the memory allocated by the system calls brkf), sbrkf) or mmap() into chunks that are more efficient and manageable.
With the heap, allocated memory is not automatically cleaned up as with the stack. The stack has a calling convention that automatically takes care of popping values off the stack and returning control to the calling function. The heap, on the other hand, requires the programmer to call a function to free the memory allocated. Failure to free the memory on the heap can result in problems including memory leakage, resource exhaustion, and fragmentation. When a user opens up a web browser, the developers of the browser have no way of knowing how many tabs the user will open, what types of pages will be visited, how much memory space is required for each site, etc. . It is this that makes the heap a more desirable location for the data than the stack.
0 comments:
Post a Comment