When we use malloc()
we say how many bytes we need. But in free()
we do not say. How does he know how much needs to be released?
When we use malloc()
we say how many bytes we need. But in free()
we do not say. How does he know how much needs to be released?
This is implementation detail, but as far as I know, they all hold 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.
This header usually contains the size allotted there and some other information. It is very common for every object in C or C ++ to contain two header words (16 bytes in 64-bit architectures). Not a small thing for small objects. There are cases that doubles. It is possible to do with just 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 instances of implementations that free()
costs more than malloc()
because he needs to maintain a freelist where he is storing the freed spaces in the most organized way possible to make it easier for malloc()
to find a suitable location for other allocations.
An important point is that the allocation is done in blocks, so do not think that sizeof
an object will actually give you the allotted size. These blocks are called arenas and are usually 16 or 32 bytes long. It is common to need more than one arena even for minimal allocations. This has some advantages, but it can bring some difficulty, in addition to the obvious extra memory consumption. An access error beyond the data area may go undetected because it still remains within its arena.
What most people do not know is that free()
does not usually free memory for the operating system, at least not in all situations, not in the hour. This freed memory becomes the property of the application and malloc()
will recycle it as much as possible.
I always teach people to give free()
no matter what code. But for the truth is that simple codes or that will run for a very short time, is probably a utility that does one thing and ends, free()
is not that necessary. At the end of the code execution 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 no one notices, because even running for hours, does not swell the memory too much, it swells a little, but no one notices. What does many activities that leak or run for days creates very complicated situations.
malloc()
is not usually used in fact In fact, it is common for more complex real-world applications to use the original malloc()
and free()
and to use a mechanism in an extra layer that manages memory in a more appropriate way for that application.
Another point is that realloc()
does not necessarily copy all contents of memory. Small blocks certainly copy, Big 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 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.
The subject is vast. There are implementations that do some pretty weird things to meet a requirement. For example in real-time systems, the time of malloc()
and free()
must be constant, which complicates implementation.
Curiously if this technique were used with array , and hence string , C would be a near perfect language:
Related: What is the purpose of the free () function? .