Update

memory_management.md

@@ -2,17 +2,17 @@
 
 In [programming](programming.md) *memory management* is (unsurprisingly) the act and various techniques of managing the working [memory](memory.md) ([RAM](ram.md)) of a computer, i.e. for example dividing the total physically available memory among multiple memory users such as operating system processes and assuring they don't illegally access each other's part of memory. The scope of the term may differ depending on context, but tasks falling under memory management may include e.g. memory [allocation](allocation.md) (finding and assigning blocks of free memory) and deallocation (freeing such blocks), ensuring [memory safety](memory_safety.md), organizing blocks of memory and [optimizing](optimization.md) memory access (e.g. with [caches](cache.md) or data reorganization), [memory virtualization](virtual_memory.md) and related tasks such as address translation, handling out-of-memory [exceptions](exception.md) etc.
 
-Memory management can be handled at different levels: hardware units such as the [MMU](mmu.md) and CPU [caches](cache.md) exist to perform certain time-critical memory-related tasks (such as address translation) quickly, [operating system](os.md) may help with memory management (e.g. implement virtual memory and offer [syscalls](syscall.md) for dynamic allocation and deallocation of memory), a [programming language](programming_language.md) may do some automatic memory management (e.g. [garbage collection](garbage_collection.md) or handling call stack) and programmer himself may do his own memory management (e.g. deciding between static and dynamic allocation or choosing the size of dynamic allocation chunk).
+Memory management can be handled at different levels: [hardware](hw.md) units such as the [MMU](mmu.md) and CPU [caches](cache.md) exist to perform certain time-critical memory-related tasks (such as address translation) quickly, [operating system](os.md) may help with memory management (e.g. implement virtual memory and offer [syscalls](syscall.md) for dynamic allocation and deallocation of memory), a [programming language](programming_language.md) may do some automatic memory management (e.g. [garbage collection](garbage_collection.md) or handling call stack) and programmer himself may do his own memory management (e.g. deciding between static and dynamic allocation or choosing the size of dynamic allocation chunk).
 
 **Why all this fuss?** As a newbie programmer who only works with simple variables and high level languages like [Python](python.md) that do everything for you you don't need to do much memory management yourself, but when working with data whose size may wildly differ and is not known in advance (e.g. files), someone has to handle e.g. the possibility of the data on disk not being able to fit to RAM currently allocated for your program, or -- if the data fits -- there may not be a big enough continuous chunk of memory for it. If we don't know how much memory a process will need, how much memory do we give it (too little and it may not be enough, too much and there will not be enough memory for others)? Someone has to prevent [memory leaks](memory_leak.md) so that your computer doesn't run out of memory due to [bugs](bug.md) in programs. With many [processes](process.md) running [simultaneously](multitasking.md) on a computer someone has to keep track of which process uses which part of memory and ensure [collisions](collision.md) (one process overwriting another processe's memory) don't happen, and someone needs to make sure that if bad things happen (such as process trying to write to a memory that doesn't belong to it), they don't have catastrophic consequences like [crashing](crash.md) or exploding the system.
 
 ## Memory Management In C
 
-In [C](c.md) -- a [low level](low_level.md) language -- you need to do a lot of **manual** memory management and there is a **big danger of fucking up**, especially with dynamic allocation -- C won't hold your hand (but as a reward your program will be fast and efficient), there is no uber memory safety. There is no automatic [garbage collection](garbage_collection.md), i.e. if you allocate memory dynamically, YOU need to keep track of it and manually free it once you're done using it, or you'll end up with [memory leak](memory_leak.md).
+In [C](c.md) -- a [low level](low_level.md) language -- you need to do a lot of **manual** memory management and there is a **big danger of [fucking](fuck.md) up**, especially with dynamic allocation -- C won't hold your hand (but as a reward your program will be fast and efficient), there is no uber memory safety. There is no automatic [garbage collection](garbage_collection.md), i.e. if you allocate memory dynamically, YOU need to keep track of it and manually free it once you're done using it, or you'll end up with [memory leak](memory_leak.md).
 
 For start let's see which kinds of allocation (and their associated parts of memory) there are in C:
 
-- **static allocation (code/data memory)**: Simplest kind of allocation happening at compile time: if the compiler can do so (i.e. if it knows enough things such as the size of the data in advance), it allocates space of concrete size at some specific address in the part of memory reserved for code or static data (code and data may be in the same or separate parts depending on platform, see e.g. [Harvard architecture](harvard.md)) -- this is straightforward, simple, automatic and poses no real dangers, bloat or burden of dependencies. This kind of allocation applies to:
+- **static allocation (code/data memory)**: Simplest kind of allocation occurring at compile time: if the compiler can do so (i.e. if it knows enough things such as the size of the data in advance), it allocates space of concrete size at some specific address in the part of memory reserved for code or static data (code and data may be in the same or separate parts depending on platform, see e.g. [Harvard architecture](harvard.md)) -- this is straightforward, simple, automatic and poses no real dangers, bloat or burden of dependencies. This kind of allocation applies to:
   - **global variables** (variables declared outside any function, i.e. even outside `main`)
   - **static variables** (variables inside functions declared with `static` keyword)
   - **constants/literals** (e.g. strings in the source code such as `"abc"`)