I want to learn about memory allocation

[HaskellHater35]

I would like you to refer me to a book on memory allocation on the computer, how it works and etc. I use the variables in my code but I don't know what it really means when I read about char having 4bytes or bool having 1byte, I want to understand how this works for maybe improve my codes, I know only the basics, that each variable has a space in the computer's memory and that a byte is 8 bits, but nothing much more, I will read in parallel to the rust book, where I am in the topic "Understanding Ownership"

[gkcjones]

This is a complicated topic, and I don't know of a book covering it fully. There is plenty of information on the internet, particularly Wikipedia, but I guess you need some starting points for what to search for.

The Book covers pretty much everything Rust-specific, and in terms of what goes on internally, Rust is similar to C/C++ and other compiled to run “on the metal” languages. (Virtual machine languages and scripting languages can be quite different, so articles about e.g. Java, JavaScript, .NET, Python etc. will be less useful.)

Basically the memory you allocate comes from three different pools:

1. Static memory is memory that is allocated at program load time, and remains allocated until the program exits. This contains executable code (compiled functions), constant data (e.g. string literals), and any variables defined static. Some of this memory may be mapped directly from the compiled executable file (e.g. via mmap() on POSIX systems), and some it just zeroed on program load.

2. Automatic memory contains variables defined with let or match etc., function arguments, and temporaries produced as anonymous intermediate values while evaluating expressions. In some cases these don’t exist in normal memory at all: small short-lived/regularly-used variables may spend their entire lifetimes in CPU registers for example. Otherwise, memory is allocated from the stack, which is a preallocated block of memory. Simplifying a lot, a stack “frame” is allocated from the stack’s memory whenever a function is called, and its automatic variables live in that frame. When the function returns, its frame is freed. When there is no space left in the memory allocated for the stack, it may be grown by the OS, or you may get a segmentation fault terminating the program. Each thread gets its own stack.

3. Dynamic memory contains data that’s explicitly put there. Box, String, Vec etc. all place their destination payloads in dynamic memory. This memory is generally referred to as the heap. Data on the heap exists from its explicit creation until its explicit destruction (although Rust uses RAII to avoid the programmer having to explicitly free memory). Heap memory can also be resized. If you need to resize memory allocations, or allocate a size known only at run time, or allocate a block too large for the stack, or if the lifetime of the data does not map to the program or function lifetimes, the heap should be used. How this works internally depends on the operating system. On POSIX systems, generally the C library allocation functions are used (malloc() etc.). Internally these use mmap() to allocate blocks of memory from the OS and subdivide them as the program needs. Of course, this rabbit hole leads to the fun of paging, virtual memory and over-commit…

There’s also thread-local storage, but I don’t know the details of how that works.

Hopefully that’s something to start with!

[grossdan]

I would suggest looking up books on embedded or even assembly language programming -- something very close to the CPU and hardware, where you work very close with the actual CPU and memory -- this would give you a great understanding of the machine that gets programmed.

Then, i would suggest looking up a book about operating systems design -- i think there is a book about Linux OS design -- this gives you a perspective on that as well.

Finally, different programming languages may have their own way to organize memory -- so this would then be Rust specific -- which you are already reading.

Dan