Let me ask you a question first: there is no information about the size of the memory block in the pointer, so how can free know how big the memory block to be released is? Therefore, for most memory allocators, the actual memory requested by malloc is several bytes larger than the space you require, and additional data is stored in it to record how big the memory is, which is usually stored directly to the left of the pointer. When free, the memory block after the pointer address minus a constant is read to obtain the memory block information. Therefore, if you free a pointer that does not point to the beginning of the memory block, other data will be incorrectly interpreted as memory block information during free, which (high probability) will cause the program to crash. Of course, modern memory allocators will adopt different allocation strategies for memory applications of different sizes, but no matter what the strategy is, it is a very dangerous move to free a pointer that is not from malloc.
How much more memory is actually allocated than requested is not specified in the standard and depends on the implementation of malloc. This is an implementation that developers do not need to care about.
There is no one-size-fits-all solution. Because this is an implementation detail of the memory allocator. If you have to know, you have to look at how the memory allocator you use allocates memory.
This part is mentioned in CSAPP. Not only will there be an extra record size header, but also more memory than requested will be obtained due to the alignment operation
The operating system needs to know how much memory is allocated for each pointer. When we called delete, we did not tell the operating system how much memory the area occupied by the pointer occupied, so there must be a place where this value is stored, and This value has different implementations in different operating systems. For example, the simplest implementation is to use a byte in front of each pointer to save the length of the memory allocation. Generally, the operating system will provide a function to obtain the actual memory size. , such as functions like malloc_size. If you are interested, you can take a look at the redis source code, zmalloc.h and zmalloc.c https://github.com/antirez/re...
I have seen it on Zhihu:
See: https://www.zhihu.com/questio...
How much more memory is actually allocated than requested is not specified in the standard and depends on the implementation of
malloc
. This is an implementation that developers do not need to care about.There is no one-size-fits-all solution. Because this is an implementation detail of the memory allocator. If you have to know, you have to look at how the memory allocator you use allocates memory.
This part is mentioned in CSAPP. Not only will there be an extra record size header, but also more memory than requested will be obtained due to the alignment operation
The operating system needs to know how much memory is allocated for each pointer. When we called delete, we did not tell the operating system how much memory the area occupied by the pointer occupied, so there must be a place where this value is stored, and This value has different implementations in different operating systems. For example, the simplest implementation is to use a byte in front of each pointer to save the length of the memory allocation. Generally, the operating system will provide a function to obtain the actual memory size. , such as functions like malloc_size.
If you are interested, you can take a look at the redis source code, zmalloc.h and zmalloc.c
https://github.com/antirez/re...
You can also learn about the implementation of tcmalloc and jemalloc