(gcc returns mem) Re: When is it time for a 1.0 feature freeze?

Walter Bright newshound at digitalmars.com
Mon Sep 4 12:14:15 PDT 2006


Bruno Medeiros wrote:
> I think Serg is right. I don't know what program he used to monitor  the 
> mem usage ("process explorer", is that the Windows Task Manager?), but 
> my test confirms what he's saying.
> 
> I made a small C program that allocs 100Mb and then frees it. I 
> monitored it with Windows XP Task Manager process list, looking at the 
> fields "Mem Usage" (physical mem) and "VM Size". Compiling with GCC 
> (3.2.3), it does free back the memory to the OS (VM Size decreases after 
> the free). I tried the program with DMC but the same does not happen: 
> the memory is not returned after the free. I don't have visual C 
> available right now so I didn't try that one.
> 
> After a google search:
> http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html
> "Occasionally, free can actually return memory to the operating system 
> and make the process smaller."
> Evidently the Windows version of libc also does the same. And seems it's 
> smart enough to return the mem not just when the top of the heap is all 
> free (what I was expecting) but also with free pages in the middle of 
> the heap. (the test program allocs two segments and frees the first only)

What your program is doing is allocating a gigantic chunk. It is a 
reasonable thing for new() to have a fork in it, and for gigantic chunks 
allocate/free them by calling the OS directly and not attempting to 
manage it. Thus you would see the behavior you see.

Try allocating a large number of small chunks, and free them.



More information about the Digitalmars-d mailing list