How to learn to understand how memory works at a low level?

Question

Programming

Faced with the fact that I know the theory about the heap and the stack, but the visual picture in my head is stubbornly not formed. Is there any way to deal with this so that it comes to mind once and for all. Or maybe there is some visual thing that allows you to understand it better?
I have already read a bunch of articles with pictures. Did not help.
Interested in the moment from. Here we declare a variable and what happens next and how further the structures and classes are located in memory.

Answer 1

Read about processors, their architectures, memory access, why caches appeared instead of RAM, etc.
The stack and heap are just an abstraction.

Answer 2

What Every Programmer Should Know About Memory

Answer 3

Faced with the fact that I know the theory about the heap and the stack, but the visual picture in my head is stubbornly not formed. Is there any way to deal with this so that it comes to mind once and for all. Or maybe there is some visual thing that allows you to understand it better?

The best option is to write your own pile.
True, this is the most laborious option for understanding.
Requires a language without garbage collection. C, Pascal, etc.

Answer 4

Of course, I could write 2 pages again with all sorts of illustrations, but I don’t see the point. Where and what did you watch that you didn't understand?
Let's say the 3rd picture, what exactly is not clear or not entirely clear here? androidexample.com/Use_of_Heap_and_Stack_memory_in...
- Fully describes this criterion.
To know more, you need to deal with operating systems -> processes -> threads -> computer architecture.

Answer 5

The main thing to remember is that memory is flat, i.e. represent it simply as a set of bytes following one after another. And it doesn't matter what structures you build in flat memory, three-dimensional or five - they must all be mapped to flat memory.
When the OS loads a program for execution, it divides all the memory available to the process into 3 groups:
1. the area where the program code is loaded. This memory is usually marked read-only by the OS. And if there is an attempt to write there, then this will cause an exception in the processor.
2. Stack area. The address of the top of the stack is written to a processor register. When local variables are allocated in a program, they are placed on the stack.
In fact, there is no need to allocate memory to push a variable onto the stack. When compiling the program, the compiler counts offsets relative to the beginning of the stack, and local variables are accessed by the pointer to the beginning of the stack + offset.
There is an interesting story with the stack: the OS allocates a fixed amount of memory for the stack, but the stack size itself is not stored anywhere (it is not explicitly stored, but you can find it in), only a pointer to the beginning is stored. So there is always a chance of a stack overflow. For example if to make rather deep recursion.
In modern operating systems, a sufficiently large amount of memory is allocated for the stack, so overflows usually do not occur. But sometimes the program requires a larger stack size, then the required size is specified using the compiler options, this size is sewn into the executable file, and when the OS loader loads the program, it reads the stack size and allocates the required memory area.
If you encounter a stack overflow in your program, then do not rush to allocate more memory for the stack, you may have a programming error due to which an overflow occurs.
3. Heap. Memory is allocated there for dynamic variables. Memory is allocated by the OS on request. Typically, in your program, you use the standard library heap manager, which in turn calls the OS for memory allocation. The heap manager from the standard library can be changed, there are free freely distributed implementations. Or make your own or use OS calls to allocate memory.
Something like this.

Answer 6

Interested in the moment from. Here we declare a variable and what happens next and how further the structures and classes are located in memory.

Everything strongly depends on the programming language used, the type of architecture, and the perversions of programmers, researchers and mathematicians.
I recommend reading this, everything is very clear and in pictures - www.cs.virginia.edu/~evans/cs216/guides/x86.html