Window Memory Allocation Question
Author
I'm curious how Windows allocates memory. I have an app and the memory grows when a function is called but the memory does not go back down. Here is what I mean.
main()
{
int x;
int y;
.....
while(something)
{
Sleep(1000);
///Memory usage is 300K
}
Foo();
/// Memory usage is 400K after func call
}
void Foo(void)
{
char msg[1000];
char xyz[2000];
....
//func prints some messages + does minor cals
return;
}
I can understand Windows needing to allocate the memory to carry out Foo, but shouldn't the memory go back down when you come out of Foo. Thanks.
In c++, there's no garbage collection, so you've got to disallocate memory manually (with a delete) when dealing with pointers or arrays.
Did you disallocate the memory for your 2 array of char before ending the function ?
Did you disallocate the memory for your 2 array of char before ending the function ?
Author
I didn't do any dynamic memory allocation. I did it exactly like in the example. Like this...
void MyFunc(void)
{
int x;
int y;
char msg[1000];
x = 889;
y = 34;
x = x * y + 5;
sprintf(msg, "Dumb message: %d\n", x);
printf("Dumb messgae %s\n", msg);
return;
}
Shouldn't the memory be re-claimed when the function exits. Yet if I call the function repeatedly, it does not grow wildly. I mean the memory growth is the same if I call the func once VS 100 times.
void MyFunc(void)
{
int x;
int y;
char msg[1000];
x = 889;
y = 34;
x = x * y + 5;
sprintf(msg, "Dumb message: %d\n", x);
printf("Dumb messgae %s\n", msg);
return;
}
Shouldn't the memory be re-claimed when the function exits. Yet if I call the function repeatedly, it does not grow wildly. I mean the memory growth is the same if I call the func once VS 100 times.
The code is getting paged in from virtual memory into RAM. Hence the memory usage goes up. Or the stack is growing automatically increasing the RAM usage.
In the given example, the two arrays are allocated on the stack. The stack is of a fixed size, but only a certain amount is used at a given time. It can grow when needed, but infinitely (-> stack overflow) and probably shrink too, altough the shrinking isn't really necessary.
So, in your example, the "end of stack" pointer is moved around and that's pretty much it.
Also, if you use that memory usage values displayed by the task manager, be careful, because they are very very inaccurate.
I hope that helps...
So, in your example, the "end of stack" pointer is moved around and that's pretty much it.
Also, if you use that memory usage values displayed by the task manager, be careful, because they are very very inaccurate.
I hope that helps...
printf or the OS functions it calls might also being doing some sort of delayed-intialization and/or caching. This will look like a memory leak in a trivial example like this but it really isn't.
These sort of things makes leak detection hard. Try running your test for an hour in a loop. If memory usage keeps going up then you have a leak. If it goes up and then levels off you're fine.
These sort of things makes leak detection hard. Try running your test for an hour in a loop. If memory usage keeps going up then you have a leak. If it goes up and then levels off you're fine.
In a program that small there is little chance of memory getting paged in. THe whole thing would almost certainly be in memory when loaded.
And as a side note, just because you release memory doesn't mean it will show up as being released in the task manager. The memory manager can keep memory around in pools if it thinkgs it'll need it again, so the OS won't know its available.
Cheers
Chris
And as a side note, just because you release memory doesn't mean it will show up as being released in the task manager. The memory manager can keep memory around in pools if it thinkgs it'll need it again, so the OS won't know its available.
Cheers
Chris
Quote:Original post by Anon Mike
printf or the OS functions it calls might also being doing some sort of delayed-intialization and/or caching. This will look like a memory leak in a trivial example like this but it really isn't.
These sort of things makes leak detection hard. Try running your test for an hour in a loop. If memory usage keeps going up then you have a leak. If it goes up and then levels off you're fine.
Or get a Memory Manager (MMGR)
If you're watching memory usage via task manager, just stop. That column is misleading at best.
The proper way to check for memory leaks is to instrument your application with a tool like BoundsChecker or Visual Studio's debug C runtime routines. The proper way to watch memory usage is a lot harder. The size of the 'private bytes' of a process I refer to sometimes, but I am not certain how accurate it is.
The important thing is that memory is not freed up immediately if the system isn't starved for RAM. You see a lot of people crying about .NET framework apps being memory-hungry when in reality they are just poorly represented by task manager. Yes, they use more memory than C++ equivalents, but not enough to necessitate whining.
The proper way to check for memory leaks is to instrument your application with a tool like BoundsChecker or Visual Studio's debug C runtime routines. The proper way to watch memory usage is a lot harder. The size of the 'private bytes' of a process I refer to sometimes, but I am not certain how accurate it is.
The important thing is that memory is not freed up immediately if the system isn't starved for RAM. You see a lot of people crying about .NET framework apps being memory-hungry when in reality they are just poorly represented by task manager. Yes, they use more memory than C++ equivalents, but not enough to necessitate whining.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
