(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