malloc/free weird behaviour (Win32 / MsVC7)

E

Eric Nicolas

Hi,

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

Under Windows 2000, with Visual C++ 7 (.Net), I found that it
is not the case : if I allocate many small blocks and then free
them all, the total memory is not given back to the operating
system.

Below is my simple test program. If I look at the total virtual
memory footprint, I see:
- at start : 11 Mo
- after alloc : 145 Mo
- after free : 145 Mo, and it never goes back to 0.

Anyone can explain me why ?

Anyone has an idea how to give back memory to the operating
system after having freed() all the blocks ? I have also tried
a call to _heapmin(), with no more success.

Please answer me on <[email protected]>

-------------------------------------------------------

#include <windows.h>
#include <vector>

#define N 100000
#define S 1000

int main()
{
MessageBox(NULL, "Allocation...", "Test Program", MB_OK);

{
std::vector<void*> list;
for(int i=0; i<N; ++i) list.push_back(malloc(S));

MessageBox(NULL, "Free...", "Test Program", MB_OK);

for(int i=0; i<N; ++i) free(list);
} // This closing brace also frees the std::vector<>

MessageBox(NULL, "Done", "Test Program", MB_OK);
}
 
A

Alan Balmer

Hi,

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

I wouldn't count on it even in Unix. The memory is made available for
re-allocation by your program, but there's no requirement that it be
made available to the OS before your program terminates.

Some environments have a means of returning memory to the system, but
those means are off-topic here. Try a Windows newsgroup.
Please answer me on <[email protected]>
Sorry - post here, read here.
 
M

Mathew Hendry

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

No - typically the C runtime allocates and frees in larger chunks to avoid
OS allocation performance overheads.

-- Mat.
 
C

cody

Eric Nicolas said:
Hi,

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

Under Windows 2000, with Visual C++ 7 (.Net), I found that it
is not the case : if I allocate many small blocks and then free
them all, the total memory is not given back to the operating
system.

Below is my simple test program. If I look at the total virtual
memory footprint, I see:
- at start : 11 Mo
- after alloc : 145 Mo
- after free : 145 Mo, and it never goes back to 0.

Anyone can explain me why ?

Anyone has an idea how to give back memory to the operating
system after having freed() all the blocks ? I have also tried
a call to _heapmin(), with no more success.

Please answer me on <[email protected]>

-------------------------------------------------------

#include <windows.h>
#include <vector>

#define N 100000
#define S 1000

int main()
{
MessageBox(NULL, "Allocation...", "Test Program", MB_OK);

{
std::vector<void*> list;
for(int i=0; i<N; ++i) list.push_back(malloc(S));

MessageBox(NULL, "Free...", "Test Program", MB_OK);

for(int i=0; i<N; ++i) free(list);
} // This closing brace also frees the std::vector<>

MessageBox(NULL, "Done", "Test Program", MB_OK);
}



The problem could be that you should not use malloc/free in C++. use
new/delete instead.
 
M

Mark Gordon

On 17 Oct 2003 15:56:23 -0700
Hi,

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

Under Windows 2000, with Visual C++ 7 (.Net), I found that it
is not the case : if I allocate many small blocks and then free
them all, the total memory is not given back to the operating
system.

No, it makes it available for further allocations, not necessarily
available to the OS.

Please answer me on <[email protected]>

No. Post here read the replies here.
#include <windows.h>

OS specific and hence OT here.
#include <vector>

C++ and hence OT here.

<snip>

Take your Windows specific questions over to a Windows group (MS has
plenty) and any remaining C++ questions down the hall to comp.lang.c++
 
G

Gordon Burditt

I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least

"the memory can actually be given back to the operating system"
is equivalent to "the memory need not actually be given back to the
operating system".
it is the case usually under Unix.

I know of at least early one Unix variant where the only way of
giving memory back to the OS was exit(). Calling sbrk() with a
negative argument didn't actually release any memory. Calling
sbrk() with a positive argument "allocated" memory previously
"released". Even a "reasonable" OS that implements sbrk() won't
take back a block too tiny to deal with until there is a decent
size block to release. A "decent size" block is likely to
correspond to the memory management page size on systems where that
term actually has meaning.
Under Windows 2000, with Visual C++ 7 (.Net), I found that it
is not the case : if I allocate many small blocks and then free
them all, the total memory is not given back to the operating
system.

The only thing remotely required to give memory back to the operating
system is exit() (and possibly abort()), and even that isn't required
by ANSI C but would be widely viewed as a bug in a multi-tasking
operating system. Not releasing memory back to the OS is often
viewed as an OPTIMIZATION. Like most optimizations, there are
situations when it can backfire.

Gordon L. Burditt
 
M

Mark Gordon

The problem could be that you should not use malloc/free in C++. use
new/delete instead.

As I understand it you are correct that new/delete is to be preferred in
C++, however it is unlikely to affect whether the memory is returned to
the OS.

However, this discussion belongs in comp.lang.c++ for the general
question and a windows group for the specific behaviour of MS VC++
 
C

Christopher Benson-Manica

Eric Nicolas said:
I am just checking malloc/free behaviour. I thought that if I
properly do one free() for each malloc()-ed block, the memory
can actually be given back to the operating system. At least
it is the case usually under Unix.

As other people have noted, this need not be the case. An implementation may
do its own bookkeeping regarding used and free memory areas, and thus may well
not return "free" memory to the operating system. Presumably your Win2k
implementation is behaving in this manner.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top