31

I am observing the following behavior in my test program:

I am doing malloc() for 1 MB and then free() it after sleep(10). I am doing this five times. I am observing memory consumption in top while the program is running.

Once free()-d, I am expecting the program's virtual memory (VIRT) consumption to be down by 1 MB. But actually it isn't. It stays stable. What is the explanation for this behavior? Does malloc() do some reserve while allocating memory?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
user1228352
  • 437
  • 4
  • 15
  • Related: [How do I free memory in C?](https://stackoverflow.com/questions/9069205/how-do-i-free-memory-in-c) – Lundin Mar 22 '19 at 13:51
  • 2
    Possible duplicate of [Memory usage doesn't decrease when free() used](https://stackoverflow.com/questions/13232119/memory-usage-doesnt-decrease-when-free-used) – Useless Mar 22 '19 at 16:29
  • 2
    @Useless This question has better answers than the older one so I've bucked convention and marked the old question a duplicate of this one. – John Kugelman Mar 22 '19 at 18:32
  • I think nearly all malloc/free implementations use some internal management which does request larger chunks and free them opportunistically. This may use `brk(2)` or mmap. It also means that pages might not actually get used before touched (and sometimes even uncommitted on free, so the virtual or data segment size is not so important) – eckes Mar 22 '19 at 19:42

3 Answers3

42

Once free()-d, I am expecting program's virtual memory (VIRT) consumption to be down by 1MB.

Well, this is not guaranteed by the C standard. It only says, once you free() the memory, you should not be accessing that any more.

Whether the memory block is actually returned to the available memory pool or kept aside for future allocations is decided by the memory manager.

Brian McCutchon
  • 7,738
  • 3
  • 27
  • 42
Sourav Ghosh
  • 127,934
  • 16
  • 167
  • 234
  • 1
    Is it possible to release the free()'d memory block back to OS? – user1228352 Mar 22 '19 at 07:59
  • 8
    @user1228352 no, the C language doesn't allow this. If you want more control, you need to implement your own memory manager that relies on platform specific OS system calls. – Jabberwocky Mar 22 '19 at 08:30
  • 8
    @user1228352 I understand the feeling after this, let's say trickery, however - you really don't want to go that way, nor it makes sense in the long-term approach because it's just a waste of time for you to figure out how to make your own memory manager (if allowed by the OS) and debug it. Go by the C standard and you'll have more comfortable experience, while the OS does the thing it's made for. Well, unless your target is to make your own OS, but then you probably wouldn't ask this question. – Peter Badida Mar 22 '19 at 14:15
  • @user1228352 Why would you want to? Virtual memory is effectively free. – David Schwartz Mar 22 '19 at 23:27
  • @DavidSchwartz My product works in a very resource-restrictive environment. I am aware of the fact that virtual memory is NOT actually memory in use, it's free. But it is definitely the memory my process CAN use. Just want to reduce the unnecessary consumption. I am fine with delay in response or processing but can't allow increase in VIRT memory consumption. – user1228352 Mar 23 '19 at 15:34
  • 2
    Why would you want to reduce the unnecessary consumption of something that is not scarce? You should tell us a lot more about your environment if you want a helpful answer. Some unusual environments also have unusual implementations of `malloc` and `free`. If you have a real issue (and this isn't just cosmetic) you could replace the allocator with one that never holds any extra virtual memory but there's about a 99% chance it will just make things worse due to issues like fragmentation. – David Schwartz Mar 23 '19 at 18:41
  • @DavidSchwartz I think as you mentioned, this is possible but it comes with heavy cost of unreliability and risk. I fear it will make things more unstable. So, I can compromise with few more VIRT numbers with stability and reliability. Thanks for the pointers. – user1228352 Mar 25 '19 at 04:43
28

The C standard doesn't force on the implementer of malloc and free to return the memory to the OS directly. So different C library implementations will behave differently. Some of them might give it back directly and some might not. In fact, the same implementation will also behave differently depending on the allocation sizes and patterns.

This behavior, of course, is for good reasons:

  1. It is not always possible. OS-level memory allocations usually are done in pages (4KB, 4MB, or ... sizes at once). And if a small part of the page is still being used after freeing another part then the page cannot be given back to the operating system until that part is also freed.
  2. Efficiency. It is very likely that an application will ask for memory again. So why give it back to the OS and ask for it again soon after. (of course, there is probably a limit on the size of the memory kept.)

In most cases, you are not accountable for the memory you free if the implementation decided to keep it (assuming it is a good implementation). Sooner or later it will be reallocated or returned to the OS. Hence, optimizing for memory usage should be based on the amount you have malloc-ed and you haven't free-d. The case where you have to worry about this, is when your allocation patterns/sizes start causing memory fragmentation which is a very big topic on its own.

If you are, however, on an embedded system and the amount of memory available is limited and you need more control over when/how memory is allocated and freed then you need to ask for memory pages from the OS directly and manage it manually.

Edit: I did not explain why you are not accountable for memory you free. The reason is, on a modern OS, allocated memory is virtual. Meaning if you allocate 512MB on 32-bit system or 10TB of 64-bit system, as long as you don't read or write to that memory, it will not reserve any physical space for it. Actually, it will only reserve physical memory for the pages you touch from that big block and not the entire block. And after "a while of not using that memory", its contents will be copied to disk and the underlying physical memory will be used for something else.

Ameen
  • 1,391
  • 2
  • 12
  • 26
  • 1
    Note that some allocators may avoid the possibility of copying data to disk by using OS specific calls that say "these pages aren't in use, so feel free to drop their contents, even though I'm not releasing the virtual memory itself". Example would be using the `madvise` call on Linux with `MADV_DONTNEED`. – ShadowRanger Mar 23 '19 at 05:14
12

This is very dependent on the actual malloc implementation in use.

Under Linux, there is a threshold (MMAP_THRESHOLD) to decide where the memory for a given malloc() request comes from.

If the requested amount is below or equal to MMAP_THRESHOLD, the request is satisfied by either taking it from the so-called "free list", if any memory blocks have already been free()d. Otherwise, the "break line" of the program (i. e. the end of the data segment) is increased and the memory made available to the program by this process is used for the request.

On free(), the freed memory block is added to the free list. If there is enough free memory at the very end of the data segment, the break line (mentionned above) is moved again to shrink the data segment, returning the excess memory to the OS.

If the requested amount exceeds MMAP_THRESHOLD, a separate memory block is requested by the OS and returned again during free().

See also https://linux.die.net/man/3/malloc for details.

glglgl
  • 81,640
  • 11
  • 130
  • 202