can't free memory for vector in map

Discussion in 'C++' started by nw, Nov 15, 2008.

  1. nw

    nw Guest

    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, Nov 15, 2008
    #1
    1. Advertising

  2. nw

    nw Guest


    > 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, Nov 15, 2008
    #2
    1. Advertising

  3. nw

    Bo Persson Guest

    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
     
    Bo Persson, Nov 15, 2008
    #3
  4. nw

    James Kanze Guest

    On Nov 15, 7:48 pm, 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?


    Yes:). Concerning the default allocator, the standard says
    that "the storage is obtained by calling ::eek: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 ::eek: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
     
    James Kanze, Nov 16, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. pmatos
    Replies:
    6
    Views:
    23,818
  2. Replies:
    8
    Views:
    1,930
    Csaba
    Feb 18, 2006
  3. Javier
    Replies:
    2
    Views:
    567
    James Kanze
    Sep 4, 2007
  4. Panduranga Chary

    How memory function free() knows how much memory to free.

    Panduranga Chary, Dec 27, 2007, in forum: C Programming
    Replies:
    2
    Views:
    418
    Keith Thompson
    Dec 27, 2007
  5. Rushikesh Joshi
    Replies:
    0
    Views:
    364
    Rushikesh Joshi
    Jul 10, 2004
Loading...

Share This Page