Page 1 of 1

free() again

Posted: Wed Aug 27, 2003 1:36 pm
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?.

Re:free() again

Posted: Wed Aug 27, 2003 4:29 pm
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

Re:free() again

Posted: Wed Aug 27, 2003 5:26 pm
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.

Re:free() again

Posted: Thu Aug 28, 2003 1:26 am
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 ?

Re:free() again

Posted: Thu Aug 28, 2003 3:58 am
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.

Re:free() again

Posted: Thu Aug 28, 2003 4:09 am
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.

Re:free() again

Posted: Thu Aug 28, 2003 4:19 am
by dazed
Thank You.

Re:free() again

Posted: Thu Aug 28, 2003 6:46 am
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.