can't free memory for vector in map

[nw]

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++.

 

[nw]

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]

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

 

[James Kanze]

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.