«

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(identifie r);


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.

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.

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

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 :perator 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 :perator 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:
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