So I am learning C++ and I came across this problem whether we can access heap memory without a pointer or not?
Or is there any other way to access heap memory.
Related
I wish to put pointers allocated via GC_MALLOC in memory allocated with the standard malloc(). The manual says to not do this, but this memory is allocated in a library I do not have control over. Is it possible to designate the memory allocated by malloc() as uncollectable in the same way that GC_MALLOC_UNCOLLECTABLE() does for memory that it allocates? That is, so that it will know to scan that memory for pointers, but not attempt to free it.
The only alternative I can think of is to allocate some memory via GC_MALLOC_UNCOLLECTABLE() in addition to the malloc-allocated memory, just to place the pointer in both places, but I am hoping for a less awkward solution.
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.
What exactly is heap memory?
Whenever a call to malloc is made, memory is assigned from something called as heap. Where exactly is heap. I know that a program in main memory is divided into instruction segment where program statements are presents, Data segment where global data resides and stack segment where local variables and corresponding function parameters are stored. Now, what about heap?
The heap is part of your process's address space. The heap can be grown or shrunk; you manipulate it by calling brk(2) or sbrk(2). This is in fact what malloc(3) does.
Allocating from the heap is more convenient than allocating memory on the stack because it persists after the calling routine returns; thus, you can call a routine, say funcA(), to allocate a bunch of memory and fill it with something; that memory will still be valid after funcA() returns. If funcA() allocates a local array (on the stack) then when funcA() returns, the on-stack array is gone.
A drawback of using the heap is that if you forget to release heap-allocated memory, you may exhaust it. The failure to release heap-allocated memory (e.g., failing to free() memory gotten from malloc()) is sometimes called a memory leak.
Another nice feature of the heap, vs. just allocating a local array/struct/whatever on the stack, is that you get a return value saying whether your allocation succeeded; if you try to allocate a local array on the stack and you run out, you don't get an error code; typically your thread will simply be aborted.
The heap is the diametrical opposite of the stack. The heap is a large pool of memory that can be used dynamically – it is also known as the “free store”. This is memory that is not automatically managed – you have to explicitly allocate (using functions such as malloc), and deallocate (e.g. free) the memory. Failure to free the memory when you are finished with it will result in what is known as a memory leak – memory that is still “being used”, and not available to other processes. Unlike the stack, there are generally no restrictions on the size of the heap (or the variables it creates), other than the physical size of memory in the machine. Variables created on the heap are accessible anywhere in the program.
Oh, and heap memory requires you to use pointers.
A summary of the heap:
the heap is managed by the programmer, the ability to modify it is
somewhat boundless
in C, variables are allocated and freed using functions like malloc() and free()
the heap is large, and is usually limited by the physical memory available
the heap requires pointers to access it
credit to craftofcoding
Basically, after memory is consumed by the needs of programs, what is left is the heap. In C that will be the memory available for the computer, for virtual machines it will be less than that.
But, this is the memory that can be used at run-time as your program needs memory dynamically.
You may want to look at this for more info:
http://computer.howstuffworks.com/c28.htm
Reading through this, this is actually beyond the realms of C. C doesn't specify that there's a heap behind malloc; it could just as easily be called a linked list; you're just calling it a heap by convention.
What the standard guarantees is that malloc will either return a pointer to an object that has dynamic storage duration, and your heap is just one type of data structure which facilitates the provision of such a storage duration. It's the common choice. Nonetheless, the very developers who wrote your heap have recognised that it might not be a heap, and so you'll see no reference of the term heap in the POSIX malloc manual for example.
Other things that are beyond the realms of standard C include such details of the machine code binary which is no longer C source code following compilation. The layout details, though typical, are all implementation-specific as opposed to C-specific.
The heap, or whichever book-keeping data structure is used to account for allocations, is generated during runtime; as malloc is called, new entries are (presumably) added to it and as free is called, new entries are (again, presumably) removed from it.
As a result, there's generally no need to have a section in the machine code binary for objects allocated using malloc, however there are cases where applications are shipped standalone baked into microprocessors, and in some of these cases you might find that flash or otherwise non-volatile memory might be reserved for that use.
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.