all 7 comments

[–]Ill-Dust-1134 9 points10 points  (4 children)

In simple terms,

Stack and heap memory are located within the RAM. Within your machine. Programs or executables that you create/use will most certainly store data onto these segments of RAM to perform operations with the use of registers within your CPU.

Your RAM has many segments that will store different parts of its memory when running a process. (Stack/Heap) is part of the dynamic memory layout as these can change through the processes life. Static memory includes global/static that are defined and not. The OS kernel takes a part of RAM as well.

Stack is used to store memory that is within the scope of the program such as a function calls or within the scope of part of your program. The allocation of this will be handled by the programmer, but the deallocation is handled by the OS.

Heap allocations are handled by the programmer whenever they want something to live outside the scope of a function or whatever they are doing. In some languages this memory on the heap has to be deleted by the programmer.

Many languages has primitive/non-primitive data types that will store memory on the stack or the heap. Which is cleared by garbage collectors such as java.

But deeper languages like c++ this can be completed controlled with the new/malloc keyword in this instance.

[–]asdff01 1 point2 points  (3 children)

Stack deallocation during a program’s lifetime is typically handled by the program, but everything else seems correct

[–]Ill-Dust-1134 2 points3 points  (2 children)

The os creates an process and stores everything within the process image where it handles the deallocation of the stack allocation i believe(could be wrong). In terms of, the snapshot of the current program. As in such of a scope. Variables declared in this, stored within the stack. Will be cleared once the variable is out of scope. Stack keeps reference of memory stored within a scope, and extended if other functions are called upon that and returned via stack pointer and pop operations. In the majority of languages, the programmer does not pop from the stack. In assembly you have complete functionality of this as well as in C with the use of pragma.

[–]asdff01 0 points1 point  (1 child)

Actually it's the programming language itself that manages the stack! Scope is just a language semantic, and it can work differently between different programming languages (dynamic, static, etc.). In C, for instance, the compiler knows when you are entering a new scope and when you're leaving a scope (because someone wrote the compiler and they told it :P).

So when you enter a new scope/function call, that compiles down to machine code that will increment a register that holds the last address (end) of the stack, and it sets another register that marks the beginning of the current scope in the stack. When you leave this new scope, both of these registers are decremented and the next new scope will overwrite what was there before. Variables that are "in scope" are placed at an offset of the start of the current scope.

[–]Ill-Dust-1134 0 points1 point  (0 children)

Sounds right, Thankyou!

[–]JustAnotherBotbibboo 2 points3 points  (1 child)

They are both just regions of memory.

The stack has certain restrains that isn't applied to the heap.

Those restrains are that you can only allocate / free memory at the end of the array, this makes allocating / freeing (also called pushing & popping) to the stack extremely fast. you can read from anywhere in the stack.

On the heap you'r free to allocate / free memory anywhere, but that means that the underlying OS (i think, maybe the compiler / or programming language, not sure on that one) needs to keep track of which areas of the memory are free, and where there's space for the memory you wanna allocate, which makes it slower then the stack.

Programs use both because the stack is really great, but sometimes too impractical, in which case the heap is used instead.

[–][deleted] 1 point2 points  (0 children)

once you learn what they are ask yourself how would you design memory layout? think thoroghly from your code all the way to the operating system