[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

can't free memory for vector in map

nw

11/15/2008 3:51:00 PM

Hi all,

I have an issue where memory doesn't appear to be being freed from a
map containing vectors. I'm trying to use the swap trick to do this,
but my memory usage (as reported by VSize on Linux) doesn't seem to go
down.

The the following code segment signals is a map of vector<int>s.
identifier is a string index in to this.

vector<vector<int> > mst;

(signals.find(identifier)).second).clear();

(signals.find(identifier)).second).swap(mst);
(signals.find(identifier)).second).erase(identifier);


I would imagine the clear is not required and I've tried with and
without it. I'm getting to the point where I'm wondering if this is a
operating system issue rather than anything to do with C++.
5 Answers

Pete Becker

11/15/2008 4:52:00 PM

0

On 2008-11-15 10:51:04 -0500, nw <new299@googlemail.com> said:

> Hi all,
>
> I have an issue where memory doesn't appear to be being freed from a
> map containing vectors. I'm trying to use the swap trick to do this,
> but my memory usage (as reported by VSize on Linux) doesn't seem to go
> down.
>
> The the following code segment signals is a map of vector<int>s.
> identifier is a string index in to this.
>
> vector<vector<int> > mst;
>
> (signals.find(identifier)).second).clear();
>
> (signals.find(identifier)).second).swap(mst);
> (signals.find(identifier)).second).erase(identifier);
>
>
> I would imagine the clear is not required and I've tried with and
> without it. I'm getting to the point where I'm wondering if this is a
> operating system issue rather than anything to do with C++.

It's both, or neither. The operating system can tell you how much
memory it has provided for an application, but it can't tell you how
much of that memory is actually being used and how much is being held
in reserve by the application.

To see actual memory usage you have to instrument operator new and
operator delete and keep track of how much memory has been allocated
and how much has been freed.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

nw

11/15/2008 6:49:00 PM

0


> It's both, or neither. The operating system can tell you how much
> memory it has provided for an application, but it can't tell you how
> much of that memory is actually being used and how much is being held
> in reserve by the application.

By "held in reserve" do you mean by vector/map or something lower
level?

My assumption in this case is that the swap trick should forcibly free
the underlying storage and that the map erase should call the
destructor
of the map anyway. But perhaps what you're saying is that the free
doesn't
actually return the memory to the operating system, in which case is
there
a standard way to forcibly return it to the OS. In my application it
would
be useful if this could be claimed by other processes.

Bo Persson

11/15/2008 6:55:00 PM

0

nw wrote:
>> It's both, or neither. The operating system can tell you how much
>> memory it has provided for an application, but it can't tell you
>> how much of that memory is actually being used and how much is
>> being held in reserve by the application.
>
> By "held in reserve" do you mean by vector/map or something lower
> level?
>
> My assumption in this case is that the swap trick should forcibly
> free the underlying storage and that the map erase should call the
> destructor
> of the map anyway. But perhaps what you're saying is that the free
> doesn't
> actually return the memory to the operating system, in which case is
> there
> a standard way to forcibly return it to the OS. In my application it
> would
> be useful if this could be claimed by other processes.

The memory allocation layer of the standard library can hold on to the
memory allocated. There might not be any way to release parts of the
memory to the OS. There might not even be an OS at all!

The language standard has no requirements here.


Bo Persson

Paavo Helde

11/15/2008 10:45:00 PM

0

nw <new299@googlemail.com> kirjutas:

[...]
of the map anyway. But perhaps what you're saying is that the free
> doesn't
> actually return the memory to the operating system, in which case is
> there
> a standard way to forcibly return it to the OS. In my application it
> would
> be useful if this could be claimed by other processes.

There is no standard way. Typically, the heap allocator obtains relatively
large chunks of memory from OS, and gives them back according to some
internal book-keeping algorithm. The granularity here can be 1MB, for
example. Because of heap fragmentation it might not be always possible to
return extra free memory to OS.

If you work in a tight-memory environment, a quality implementation should
provide some means to control the memory allocation. However, this is then
fully an implementation-defined issue.

hth
Paavo

James Kanze

11/16/2008 12:08:00 AM

0

On Nov 15, 7:48 pm, nw <new...@googlemail.com> wrote:
> > It's both, or neither. The operating system can tell you how
> > much memory it has provided for an application, but it can't
> > tell you how much of that memory is actually being used and
> > how much is being held in reserve by the application.

> By "held in reserve" do you mean by vector/map or something
> lower level?

Yes:-). Concerning the default allocator, the standard says
that "the storage is obtained by calling ::operator new(size_t),
but it is unspecified when or how often this function is
called." (Presumable, the same holds for freeing storage.) The
implementation of the standard library thus has the right to
keep storage for later use in a container. And of course, the
standard doesn't really say anything about the actual behavior
of ::operator delete. (It says that it shall "deallocate the
storage referenced by the pointer", but it doesn't really say
what it means by "deallocate", except to state that any further
use of the pointer value is undefined. Presumably,

void operator delete( void* ) {}

is a technically legal implementation, although one could
probably complain on QoI grounds.

> My assumption in this case is that the swap trick should
> forcibly free the underlying storage and that the map erase
> should call the destructor of the map anyway. But perhaps what
> you're saying is that the free doesn't actually return the
> memory to the operating system,

The destructor of a standard container returns the memory to
its allocator. That's all that is guaranteed. There's no
guarantee that the allocator call operator delete(), and there's
no guarantee that operator delete() does anything if it does.

> in which case is there a standard way to forcibly return it to
> the OS.

You generally can't, unless you provide your own allocator.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34