How does "free()" know how much memory it has to release?

Question

When we use the malloc() we say how many bytes we need. But free() we do not say. How he knows how much he needs to be released?

Answer 1

Booking

This is implementation detail, but as far as I know they all keep the size that was allocated before the object. Then the pointer that is returned to you is to the beginning of the object, but not to the beginning where there was the allocation to it. There is a header before the object.

This header usually contains the size allocated there and may have some more information. It is very common for every object in C or C++ to contain at least two header words (16 bytes on 64-bit architectures). It is no small thing for small objects. There are cases that it bends. It is possible to do with only one word, but some price will be charged, probably in performance and impossibility to do something that is normally allowed, maybe concurrent access.

There are cases of implementations that the free() costs more than the malloc() because he needs to maintain a freelist where it stores the spaces released in the most organized way possible to facilitate the malloc() find a suitable location for other allocations.

An important point is that the allocation is done in blocks, so don’t think that the sizeof of an object will give you the actual allocated size. These blocks are called arenas and usually have 16 or 32 bytes. It is common to need more than one arena even for minimal allocations. This has some advantages, but can bring some difficulty in addition to the obvious extra memory consumption. An access error beyond the data area can go unnoticed because it still stays within your arena.

Remembering that this can change in certain implementations.

Release

What much does not know is that the free() does not usually release memory to the operating system, at least not in all situations and not on time. This memory is left as property of the application and the malloc() will recycle it as far as possible.

I always teach people to give a free() no matter the code. But the truth is that simple codes or that will run for a very short time, probably because it is a utility that does a thing and ends, the free() not so necessary. At the end of the execution of the code all memory will be released by the operating system. And that’s even faster than doing it manually.

I know a lot of desktop application with memory leaks that nobody notices, because even running for hours, does not swell the memory too much, swells a little, but nobody notices. What makes many activities that leak or run for days create very complicated situations.

malloc() is not usually worn in a suit

In fact it is common for more complex real applications not to use the malloc() and free() and use a mechanism in an extra layer that manages the memory more properly for that application.

Relocation

Another point is that the realloc() does not necessarily copy all content from memory. Small blocks certainly copies, large probably not, at least not all of it. Virtual memory is a linked list in the operating system, so a realloc() can only rearrange the addresses of the memory pages in this linked list and do not need to copy much of the content. The cost is not zero, but it is much faster than copying the content.

Completion

The subject is vast. There are implementations that do some pretty weird things to meet a requirement. For example in systems real-time, of truth the time of malloc() and of free() needs to be constant, which complicates implementation.

Interestingly, if this technique were used with array, and consequently string, C would be an almost perfect language :P

Related: What is the purpose of the free function()?.