470,833 Members | 1,195 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,833 developers. It's quick & easy.

Delete does not really delete

I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.

Goshiwen
Jun 27 '08 #1
4 3915
Hong Chen wrote:
I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.
I am not sure if this is in the FAQ (have you looked?) but about once
a month we get this question. Please post to the newsgroup that deals
with your platform. Whatever "performance monitor" tells you cannot
have anything to do with the language, and everything to do with your
OS.

Your guess about "heap allocator" and its relation to "future use" of
"deleted memory" is about as good as mine. Any way to "force the
release" would certainly be plaform-specific, don't you think?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 27 '08 #2
Hong Chen wrote:
I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.
In most OS's, when you allocate memory the program asks the OS to
increase the heap for the process. It never asks it to reduce it. (And
even if in some OS programs would have the means to do that, memory
fragmentation would probably often stop them from being able to do it.)

Thus in most OS's the memory taken by programs never decreases. OTOH
that's what swapping is for.
Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.
The default allocator used in C and C++ programs will reuse heap
memory whenever it can. That's not the problem.
Jun 27 '08 #3
Juha Nieminen <no****@thanks.invalidkirjutas:
Hong Chen wrote:
>I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

In most OS's, when you allocate memory the program asks the OS to
increase the heap for the process. It never asks it to reduce it. (And
At least the C++ implementatons and OS-es I have used do reduce the
process memory (Windows and Linux). There is some granularity though, it
used to be 1MB in Windows IIRC.
even if in some OS programs would have the means to do that, memory
fragmentation would probably often stop them from being able to do it.)
That's what the virtual address space is for. Maybe the typical size of a
single allocation also plays a role, if you have a single byte allocated
in each hardware memory page (4096 bytes for x86 IIRC), then you really
can't release any of them.
>
Thus in most OS's the memory taken by programs never decreases. OTOH
that's what swapping is for.
We routinely monitor the program workset memory as seen by OS and it
definitely decreases and increases (with megabyte granularity, but that's
ok for us).
>
>Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.
I bet the problem is somewhere else.
>
The default allocator used in C and C++ programs will reuse heap
memory whenever it can. That's not the problem.
That's true.

Best
Paavo

Jun 27 '08 #4
On Jun 2, 7:12*pm, Hong Chen <HongChe...@gmail.comwrote:
I developed a large program and found the program does not really
release memory after the delete operation is taken, since, according
to "performance monitor", the virtual bytes used by this process does
not decrease after 'delete'.

Is this because the heap allocator holds the deleted memory for future
use? Is there anyway to force the release of the memory since we
confront problem of memory allocation failure if the delete memory is
not really released.
There is also the possibility your freestore is fragmented.
If there are deleted chunks of memory in the middle of
the freestore, it is unlikely these will be given back
to the OS. Indeed, in extreme situations, you can wind
up walking your freestore and running out of memory when
you only have a very small amount of actually-used memory.

You can sometimes get a profiling tool to detect such
situations. (Though it's off topic here. Ask in a news
group dedicated to your compiler and operating system.)
If that is the case, and it is a problem, there are many
ways to approach the situation. For example, you can take
more direct control of memory allocation, in such ways
as allocating a bunch of a particular object, then you
can re-use them as needed. Such things as a the named
ctor idiom are good places to start your research.
Socks
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by | last post: by
20 posts views Thread by Ioannis Vranos | last post: by
15 posts views Thread by Roy Smith | last post: by
16 posts views Thread by robert | last post: by
2 posts views Thread by Bob Tinsman | last post: by
29 posts views Thread by Jon Slaughter | last post: by
15 posts views Thread by LuB | last post: by
19 posts views Thread by Daniel Pitts | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.