Memory Footprint! Have a vague idea on how memory is allocated/de-allocated when variables/pointers are declared/initialized/de-referenced. Wanted to have a more clear understanding.... Also, say when a function is in execution, there will be local variables. From where will the memory allocated to these variables come from? Is the heap memory related to this? and how it is used...
We can also discuss the possibilities of memory corruption. Or how the de-referencing of pointers could lead to Segmentation fault (what actually happens in memory during a Seg. Fault)
A good link with pictorial explanation will also be appreciated :)
Memory allocation is divided to two types: static allocation and dynamic allocation Static allocation is simple, the program preserves special places in memory for the data at all time. Static allocation can be seen in form of 'globals' and 'static variables' inside functions. Dynamic allocation is also divided into two mechanisms: stack and heap The stack is simple. There is a stack pointer (usually saved in a special register in the processor) initially pointing to the 'stack origin'. When you want to allocate X bytes you just move the head X bytes by changing the pointer. When you're done you restore it to the previous location. There are different types of stacks, for example stacks that go 'up' so when you allocate you have to decrease the stack pointer. That's where local variables come from. When a function enters it first allocates all the memory it requires for the local variables and then when it exits it must(!) restore the stack pointer to where it was before the allocation. Passing parameters to functions and return values back from functions is often done using the stack as well. What's important to notice is that in case of function calling another, the inner function will move the stack pointer and restore it and when the execution goes back to the outer function it will see no difference. The stack management is simple, clean and neat, but it works only for local dynamic allocations. The heap comes for 'global' dynamic allocations. What it means is that what you allocate is not limited to a scope like with the stack and can live longer. The heap management requires keeping track of what is being allocated and what is free. That means there has to be a special utility managing the heap (malloc library for example). Your application has use that manager utility in order to allocate memory. So if your program wants to allocate a block of X bytes it asks the manager. If the manager has found such a block available, then it marks it as allocated and gives you back a pointer. If not then you'll get an error (null pointer or exception..) When you're done with it you can tell the manager to 'free' this memory so it is no longer marked as allocated and can be used again for new allocations. If you have a garbage collector, then it will try on its own to recognize when the memory is no longer required and free it automatically. Well I left many details out, just tried to focus on big picture. I hope it's clear Here is a video about the topic: https://www.youtube.com/watch?v=450maTzSIvA
i'll go through that video, thanks! How about calling a function, inside a function and then returning back to caller function... There is something like program memory, right? The inside function's memory --- is it an entire new memory location independent of caller function's memory... how about stack pointer in that case...
The calling function has to pass to the inner function a return address, it also can be done using the stack. Once the inner function has finished execution and restored the stack pointer it jumps to this address and the calling function continues
that makes sense yes, so the new memory is independent... there's just passing of pointers to get back to execution step from where the function is called... All the stacks are at different memory locations? those for passing parameters and others?
Usually there is only one stack, it is used for everything When a function is called the values for the parameters along with the return address can be passed through the stack, then the inner function uses same stack to allocate the local variables When the function is done it restores the stack pointer to what it was before the allocation, pass a return value as well using the stack and jumps to the return address
What is important to understand is that since allocation is done only in one direction (decreasing the stack pointer for example) then allocations on the stack do not interfere with what is already allocated, because that is 'behind' the stack pointer.
right so the called function's stack contents cannot overlap/overrwrite calling function's stack contents!
Yes, if it follows the rules =) It also have to restore the stack pointer correctly, or after it goes back to the calling function the stack is not properly restored All those stack related stuff are managed by the compiler, but there could be a problem if you use a library that uses the stack in the opposite direction for example.. hypothetically
For that reason the processors usually give you special instructions to work with stack, like PUSH and POP that work in one direction and you should follow this direction. There are cases that are more flexible
Join our real-time social learning platform and learn together with your friends!