it'll call mmap (probably), which will then find 1GB(+ overhead) of contiguous address space<p>mmap will go and create the page table mappings (entries) for that address space (~262144 of them with 4k pages)<p>unless someone's been messing with overcommit: the physical memory allocation is normally lazy<p>this is done by setting the "faulted" bit on the allocated page table entries<p>when the application first reads/writes from a page not yet allocated: a fault will occur, the kernel will step in, (hopefully) find an unused physical 4kb of memory, update the page table entry to point to it, unmark the faulted bit, then return to the application (which will be blissfully unaware that anything happened)
Suppose you WANT malloc to be eager (i.e. make sure all the pages are committed right away, so you don't pay a performance penalty for it later), what do you do?<p>The obvious answer is just looping through it and setting it to zero would be replaced with a call to `calloc` by an optimizing compiler, and doesn't calloc also do some kind of similar "lazy" trick? So what do you do? Mark the pointer as volatile and loop through it and set all the memory to 0 (or some other value)? Call memset, I guess?<p>EDIT: apparently malloc + memset compiles to calloc as well [0], so if you want to allocate, zero out memory, and make sure it's committed, using volatile seems like the best bet to me...<p>[0]: <a href="https://godbolt.org/z/qhaaYc" rel="nofollow">https://godbolt.org/z/qhaaYc</a>
malloc() is a C (and C++) Standard Library function that you could write user-level code for yourself (in fact, there's an extended exercise in TCPL to do just that). It doesn't do the low-level handling of pages - that's down to the Linux kernel.
Is this why when I create an encrypted RAM drive that Linux shits itself? I assume that it should not fill itself up yet it does almost instantly and brings the system, down to its knees.