This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do malloc() and free() work?
I read somewhere that calling free twice using the same pointer argument causes undefined behavior. So how does free know how much memory it has to free? Does the heap always allocate contiguous memory when we call malloc/calloc/realloc? Please provide links to relevant articles/posts/blogs etc.
How malloc and free work is implementation defined. Commonly the info about the memory block would be stored in a header just below ptr. But not necessarily.
The great thing about malloc and free is that you don't need to know how they work. The system takes care of the details for you.
I read somewhere that calling free twice using the same pointer argument causes undefined behavior. In order to understand this I must first know how free works?
I'm not sure I agree with this statement. You simply need to follow the rule.
Does the heap always allocate contiguous memory when we call malloc/calloc/realloc?
If you mean that the block of memory returned is contiguous in the address space, then yes that is so. If you mean that successive allocations are sequential, then no.
You can read about an example implementation on the tcmalloc page. It's relatively short and straight forward: http://goog-perftools.sourceforge.net/doc/tcmalloc.html (jump down to Overview)
If you're wondering how malloc requests memory from the OS, it's typically by either calling sbrk or mmap. But that's implementation defined of course.
If you want to see an implementation, look for glibc, which is the GNU implementation of the C standard library, which includes the memory management functionality. But be aware that the exact detail of implementation will be different on other platforms and may change between versions of the standard library.
Related
I have to recode these 3 functions in C and the goal is that the recoded functions have to replace the system functions in different programs or system calls.
I don't really understand what is the behaviour of these functions since I've read the mans, I just know I'm allowed to use brk() and sbrk().
malloc basically pre allocates memory pages (Cf getpagesize(2)), and returns pointer to usable parts of those pre allocated areas when called.
malloc then have to "remember" which part of those pre allocated memory segments are being used, and which one are free.
Reading this article: https://www.cocoawithlove.com/2010/05/look-at-how-malloc-works-on-mac.html might help! (I know it was great help to me when i re-coded malloc on mac Os as an university assignment ;)).
This question already has answers here:
How does free know how much to free?
(11 answers)
Closed 9 years ago.
I understand that using calloc() and malloc() will allocate the specific amount of memory on the heap and return a pointer to the beginning of the allocation.
I also know that free( poinerVar) will de-allocate (free up the allocated memory). However, I cannot visualize how free() knows the amount of memory to de-allocate. Managed languages such as C#, Java keeps track of it's objects for garbage collection, but C surely does not (as far I know).
What is happening at the memory management level that enables the de-allocating of memory using free and passing it just the pointer variable.
The usual approach here is that memory allocation functions are storing metadata about allocated space before actual memory chunk.
In that way, free() just can read memory in front of the actual allocated block and it can find out how much memory should it actually deallocate.
The C standard(s) do not say how that malloc/free works under the covers. Only the external behavior. If you really want to understand it, you need to look at a specific implementation. Check out an open source libc, like the one used by GNU/gcc.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
c difference between malloc and calloc
Why does calloc require two parameters and malloc just one?
I've noticed this with many C functions calls particularly ones that deal with memory or file operations, but not all of them use both parameters. For instance malloc is passed one parameter, the size in bytes of the memory space needed. Calloc on the other hand is passed two parameters, the size in bytes of an element and the number of elements (size and nmem). There are other functions that use these size and nmem parameters as well.
Essentially the calloc call would allocate the same amount of memory as calling malloc(nmemsize) so all that's really happening is the asterisk () is replaced with a comma (,). At least this is all I can tell from the higher level that I am working at. I don't see a difference from calling calloc(1, nmemsize), calloc(nmemsize, 1), or calloc(nmem, size).
Is there something actually happening at a lower level that makes calling for instance calloc(1, nmem*size) fundamentally different from calloc(nmem, size)?
Edit: I know the functional difference between calloc and malloc. I'm interested in why there are differences in the parameters. There are other functions that use 2 size parameters for the total size (fread, fwrite, etc). I'm not concerned with the specific functions but rather why there are two parameters for the total size used in the function when essentially the total size becomes the two parameters multiplied together. I find most of the time when I use these functions I use the size that I need in the "size" parameter and a '1' for the "nmem" (sometimes "count" etc.) parameter.
In a comment to the question, I wrote that calloc() allows better memory alignment for platforms where it matters. I haven't been able to find anything to support that (yet). I am pretty sure it was a feature of the VMS/VAXC compiler, but source for that is scarce.
However, I did find that calloc() and alloc() appeared at the same time, with the release of Unix V6 in May 1975. In V5, released 11 months earlier, neither function is present; the kernel and runtime library (and assembler and C compiler) were written in assembly.
In the V6 release, calloc is implemented as the four line source code module:
calloc(n, s)
{
return(alloc(n*s));
}
calloc() does not clear the allocated memory; see alloc(), and there was no man page for calloc() in V6; however the man page for alloc():
DESCRIPTION
Alloc and free provide a simple general-purpose core management package.
Alloc is given a size in bytes; it returns a pointer to an area at least that size which
is even and hence can hold an object of any type. The argument to free
is a pointer to an area previously allocated by alloc; this space is made available for further allocation.
Needless to say, grave disorder will result if the space
assigned by alloc is overrun or if some random number is handed to free.
The routine uses a first-fit algorithm which coalesces blocks being freed with other
blocks already free. It calls sbrk (see "break (II))"
to get more core from the system when there is no suitable space already free.
DIAGNOSTICS
Returns -1 if there is no available core.
BUGS
Allocated memory contains garbage instead of being cleared.
Not even NULL is returned in the case of memory exhaustion!
calloc() first formally appears in UNIX V7, January 1979, along with several other improvements:
calloc() clears the memory returned.
alloc() was renamed to malloc()
realloc() appeared
in the case of memory exhaustion or a heap error, the functions "return a null pointer (0)"
Is there something actually happening at a lower level that makes calling for instance calloc(1, nmem*size) fundamentally different from calloc(nmem, size)?
This attempt to explain things is purely dependent from the libc implementation - and therefore left at the appreciation of a specific libc author:
Since calloc() is zeroing memory, the rationale might have been that it could (potentially) waste some more cycles at doing a mult.
In contrast, malloc() is given a chance to use a precalculated value, potentially reducing the overhead in a call that migh be simpler to satisfy.
Don't forget that C was designed at a time when each CPU cycle was costing a lot - hence a very lean design as compared to many other 'higher-level' languages.
This question could probably be better answered by the author of C Dennis Ritchie.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
C programming : How does free know how much to free?
How does free() know how much memory to be free'd which was earlier allocated by malloc() or calloc()? I mean, both of these functions receive size as parameters, while free only needs the pointer to allocated memory. Then how does free() know that how much to free?
You don't need to know.
It could use any mechanism, it's up to the folks implementing the standard library to decide.
A typical approach is to store block information somewhere just before the pointer returned to the application, but you could also use a totally separate data structure to keep track of allocations, perhaps some kind of tree where the pointer is used as a key to look for information describing that allocation.
If you really want to know, to learn, you can of course read the source code for open sourced C standard library implementations, of which there are at least a couple.
The C standard mandates that the same address returned by malloc be passed to free to deallocate the dynamic memory, So it is clear that malloc maintains some kind of table or mapping for each allocated address (mind you, exact details are unspecefied) where it stores the size of the allocated memory against the address and so it knows exactly how much memory was allocated for every address it returned back to its callers. In a free call it would lookup this mapping to know how much memory to deallocate.
Generally, you have in the free store something like a linked list of allocated resources. The memory manager is going to search that list for the memory block, remove it from the list of allocated resources and insert it back to free resources allowing it to be called again by the allocation functions. How this is done depends on the compiler implementation.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C programming : How does free know how much to free?
Hi,
When using malloc(), we specify the size of the allocation, so it knows how much to allocate. However, how does free() knows how many bytes to release? The pointer contains only the starting address of the memory block, not the length of memory block.
Thanks and Regards,
Tazim.
The answer to this is implementation-dependent; the malloc library keeps track of the length somehow, but exactly how it does so is not specified by the C language standard.
A typical approach is to store some header information (including length) before the "starting address" that malloc returns to the caller.
Malloc saves the size of the allocated pointer in some kind of data structure. When you call free it looks up the entry in this data structure and free's that much memory.
When you allocate memory, the run-time library also maintains some internal structures. It has to in order to keep track of what parts of the heap have been allocated. This information also tells it the size of a block of memory given a pointer to that memory.
It depends on the implementation but there's a good chance this information is stored just before the pointer returned.
It's implementation-specific. Some techniques:
There may be more than one pointer. An arbitrarily complex structure could be allocated and you just get a pointer to the user-payload area. The library knows the fixed offset between the pointer given to you and the pointer to the origin of the structure. The other fields could be the size and the links that thread free blocks together.
There may be a separate dictionary. This can have memory-management advantages. One problem with using the allocated block for book-keeping is that the library itself ends up writing to many if not most of the allocated pages. This keeps them dirty (in an MMU sense) and can also prevent them from being shared following a fork. This is a big problem for web servers and has led to specialized implementations of web language systems ("Ruby Enterprise") that differ mainly in memory management core.