Lucid

As a programmer, you deal with memory all the time—it’s where you store variables and data. Most of the time, you probably don’t think too much about it, except maybe to not use too much of it. But behind the simple interface of getting and setting variables and allocating and deallocating blocks of memory lies a surprising amount of complexity. In the tradition of other “Falsehoods Programmers Believe” lists, here is a list of assumptions programmers might make about the way memory works.

Allocating memory never fails.
If allocating memory succeeds, then writing to the allocated memory will always succeed.
If your system is out of memory, then allocating will always cause your program to crash.
If your system crashes due to running out of memory, it will always happen during an allocation.
A single metric can tell you how much memory your process is using.
It is safe to allocate memory in the child process after forking.
Allocating memory is always fast.
Allocating memory is always slow.
The garbage collector will return memory to the system.
If you free memory, it immediately returns to the operating system.
Garbage collection means you can't leak memory.
No other processes can directly read the memory in your process.
Processes run by the same user or by root are able to inspect the memory of your process for debugging or similar in all environments.
If you store sensitive data in memory, it won't ever be written to disk.
The address space of a process is contiguous.
Dereferencing an invalid pointer will always cause a segfault.
The "free" memory is the maximum amount of memory that is available for additional allocations.
Accessing memory randomly is just as fast as accessing it sequentially.
Writing to a location in memory doesn't require the entire page to be copied.
Writing to memory doesn't increase the amount of actual memory used by the process.
Single-event upsets (SEU) never happen.
Single-event upsets only happen in space.
Hardware and/or the OS will protect you from single-event upsets.
The RAM will never have a hardware fault.
Variables are always stored in main memory.
You will never run out of stack space.
You will never run out of heap space.
The stack is always the same size.
The stack is always the same size on a given machine.
All threads within a process always have the same size of stack.
Frames on the stack all follow the same standard format.
How data is organized in memory doesn't really matter.
Using more memory is always bad.
When address space layout randomization is used, it is impossible to exploit memory bugs.
When a W^X policy is used, it is impossible to exploit memory bugs.
Memory is never aliased.
You can do a better job of caching files than the OS.
The OS will do a better job of caching than you in all situations.
The stack always grows down.
The stack always grows up.
Other threads immediately see changes to memory.
Writing primitive values to memory is atomic.
The garbage collector will free the memory (and call the finalizer) as soon as you are done with it.
The garbage collector will free the memory (and call the finalizer) soon after it is no longer live.
ECC RAM will never become corrupted.
The virtual address space of a process exactly corresponds with how much physical RAM that process is using.
The total memory in use is the sum of the memory used by all processes.
Accessing memory won’t have to wait for disk I/O.

Did I miss anything? Are there any assumptions that you have made about memory that ended up biting you? Is there anything on this list you disagree with? Leave them in the comments, and I’ll add them to the list. See also:

Thanks to the following for contributing: Ella Moskun Ben Dilts Stephen Rollins Daniel James

Falsehoods programmers believe about memory

About Lucid