free() again

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
dazed

free() again

Post by dazed »

when a process request X amount of memory from the kernel using malloc, I understand that malloc calls mcore which allocate and maps the physical memory onto the process address space.

How about free? Is there a way of releasing the Physical memory back to the kernel?.
Slasher

Re:free() again

Post by Slasher »

yeah,you have to reverse the process.
malloc and free are allocating linear memory from the processes address space.
so say you have allocated addresses 1,2,3,4,5,6...
there is usually a small data structure before these addresses(depends on how you implemented malloc) that has pointers to the next address in the list of either free or allocated memory in the address space. all you have to do is,subtract the size of that struct from the address you are trying to free, then use the pointers for the free list to insert that address back into the list. It seems complicated,but its not. seach memory management of similar keywords on this forum,we've discussed the topic at length.
hope this helps
Tim

Re:free() again

Post by Tim »

free generally returns a memory block back to the heap, so that a future malloc can grab it again easily. It generally does not release it back to the kernel, since allocating and freeing memory via the kernel is generally considered to be slow. User-mode malloc and free tend to keep hold of memory as long as they can, to avoid allocating more memory from the kernel.

However, there's no reason why free can't consolidate blocks and give them back to the kernel every so often; however, it should not free back to the kernel on every call to free.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:free() again

Post by Pype.Clicker »

and usually, the kernel will use virtual memory mechanisms (i.e. "used" and "dirty" bits) to know which pages are no longer in used by the process and swap them out -- which allows for newer process to reclaim unused physical memory of older processes.

However, it has the obvious drawback that the kernel cannot tell whether page X's content may be discarded or should be kept in the swap ...

having a "list of discarded pages" editted by the user-level allocator that the kernel can check when reclaiming memory might be interresting ... did someone heard of this before ?
Tim

Re:free() again

Post by Tim »

I would consider a physical page discarded only if its corresponding VM area had been freed. Otherwise, a dirty page would need to be swapped to the hard disk. A non-dirty page (a page that a program had allocated but not used) could be discarded; when needed again, a new blank page could be substituted.
Adek336

Re:free() again

Post by Adek336 »

ah, so the user apps have got their own copy of malloc()/free() instead of having them as a system call? This way, sbrk() would be a syscall, yes?

Cheers,
Adrian.
dazed

Re:free() again

Post by dazed »

Thank You.
Tim

Re:free() again

Post by Tim »

Adek336: Yes. malloc and free are much faster if they are given their own big chunk of memory to divide up. That way they only rarely need to call the kernel, to obtain the next big chunk.
Post Reply