17

So I have this program that allocates 256 MB of memory, and after the user presses ENTER it frees the memory and terminates. 

#include <stdio.h> #include <stdlib.h> int main(void) { char *p, s[2]; p = malloc(256 * 1024 * 1024); if ( p == NULL) exit(1); printf("Allocated"); fgets(s, 2, stdin); free(p); return 0; }

I ran this program multiple times and backgrounded each of them until there is no longer enough memory that can be allocated. However, that never happens. I ran a linux top command and even after running this program many times, the free memory never goes down by nearly as much as 256 MB.

However, on the other hand, if I use calloc instead of malloc then there is a HUGE difference:

p = calloc(256 * 1024 * 1024, 1);

Now if I run the program and background it, and repeat, every time I run it, the free memory goes down by 256 MB. Why is this? Why does malloc not cause the available free memory to change, but calloc does?

Improve this question
6
  • Run the program via strace, and see what it does. (I'd expect both versions to mmap /dev/zero anonymously, BTW) Commented Nov 15, 2013 at 1:08
  • 8
    It's called "Lazy allocation". stackoverflow.com/questions/712683/what-is-lazy-allocation Commented Nov 15, 2013 at 1:08
  • 2
    The short, oversimplified answer is that since you haven't actually used the memory from malloc, the computer doesn't need to actually give it to you yet. With calloc though, the memory needs to be used (for the zeroing out part), and hence the computer actually needs to give you all of it. Commented Nov 15, 2013 at 1:09
  • 2
    The top and free commands' "free memory" figures are meaningless. At best they're telling you about cache efficiency. The actual meaningful number, commit charge, can be found in /proc/meminfo as the Committed_AS: line. Commented Nov 15, 2013 at 1:25
  • @DennisMeng: this is only true for extremely primitive calloc implementations – but Ryan is apparently using one of those. BSD omalloc, for example, does not usually access the memory. Commented Mar 31, 2014 at 20:49

3 Answers 3

Reset to default
29

malloc() does not use memory. It allocates it.

After you allocate the memory, use it by assigning some data.

size_t Size = 256 * 1024 * 1024; p = malloc(Size); if (p != NULL) { memset(p, 123, Size); }

Some platforms implement malloc() is such a way that the physical consumption of memory does not occur until that byte (or more likely a byte within a group or "page" of bytes) is accessed.

calloc() may or may not truly use the memory either. A system could map lots of memory to the same physical zeroed memory, at least until the data gets interesting. See Why malloc+memset is slower than calloc?

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Is 123 your lucky number? 256 MB of 123 123 123 123… Must be very lucky!
surely it should be 42
13

The memory may not be really available, especially that you didn't do anything using p in your example except check for if it's NULL. From man malloc

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer. For more information, see the description of /proc/sys/vm/overcommit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation /vm/overcommit-accounting.

Improve this answer

Comments

5

The calloc on your system† actually touches the memory by clearing it, and on many systems memory is not really allocated (and thus “used up”) until it is touched by the process to which it is allocated. So just doing malloc does not “use” the memory until you, well, use it.

† See comments

Improve this answer

3 Comments

I think calloc() can cheat too on some systems stackoverflow.com/questions/2688466/…
@chux Interesting, I did not know that, thanks for the link. (Meanwhile the asker did find calloc and malloc different on their system and their parameters.)
Agreed. It is not well know and certainly does not apply in OP's case. Those sneaky OS gremlins!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.