Here’s something very fundamental to how memory works in operating systems, but most forget it over time. A quick reminder - when you call malloc(), you are not actually getting memory - you are getting a promise.
When you malloc 1GB, the OS says, “Sure, here’s 1GB,” but does not hand over any bytes yet. What gets allocated is virtual memory; your actual RAM usage, called RSS (Resident Set Size), stays flat.
This is lazy allocation. The OS only assigns real pages when you write to them. You can malloc() terabytes on a laptop with 16GB RAM, and the call will succeed. The crash (the infamous segmentation fault) comes later, when you try to use it, and the system cannot deliver.
malloc(1GB)-> virtual mem +1GB, RSS +0MBmemset(ptr, 0, 1GB)-> RSS +1GB
Why does this matter? Because RSS is what actually competes for resources. It is what the OOM killer looks at, and this is what slows down your system.
You can have a process showing 10GB allocated in your profiler while only consuming 2GB of actual RAM. The difference kicks in because most of those malloced regions were reserved but never touched.
By the way, this is why memory leaks can hide for so long. If you malloc() and lose the pointer without writing to it, you have leaked virtual address space but not physical memory.
The easiest way to see the RSS of your process is by running ps aux. In the output, you will see VSZ (virtual) vs RSS (resident) in KB. You can do this programmatically as well :)
So, always keep an eye on RSS, and not just track malloc allocations, to understand how much memory a process is actually consuming.