STL v. Norma" Memory Allocator

Discussion in 'C++' started by Scott Brady Drummonds, Jan 30, 2004.

  1. Hi, everyone,

    A coworker and I have been pondering a memory allocation problem that we're
    having with a very large process. Our joint research has led us to the
    conclusion that we may have to replace the STL allocator. But, before I
    even attempt something like this, I wanted to ask some questions to this
    group:

    1) We read online that STL caches allocated memory so that containers and
    their contents that are freed at one point in the program are available to
    other STL containers, but not to code that would attempt to get memory from
    the free store. Is this correct?

    2) It appears that the same is the case with the "normal" memory allocator
    (which we've been calling the 'glibc' memory allocator; is this a misnomer).
    Memory that has been released from the program with the 'delete' statement
    is available to other calls to 'new' but not to memory being allocated by by
    the STL memory allocator. Is this right?

    The conclusion here seems to be that a program that allocates large chunks
    of memory using both the STL allocator and glibc allocator is doomed to be
    quite memory-inefficient. If avoiding the usage of both of these allocators
    is impossible in our program, what hope do we have?

    Thanks,
    Scott

    --
    Remove ".nospam" from the user ID in my e-mail to reply via e-mail.
     
    Scott Brady Drummonds, Jan 30, 2004
    #1
    1. Advertising

  2. Scott Brady Drummonds

    tom_usenet Guest

    On Fri, 30 Jan 2004 09:02:09 -0800, "Scott Brady Drummonds"
    <> wrote:

    >Hi, everyone,
    >
    >A coworker and I have been pondering a memory allocation problem that we're
    >having with a very large process. Our joint research has led us to the
    >conclusion that we may have to replace the STL allocator. But, before I
    >even attempt something like this, I wanted to ask some questions to this
    >group:
    >
    >1) We read online that STL caches allocated memory so that containers and
    >their contents that are freed at one point in the program are available to
    >other STL containers, but not to code that would attempt to get memory from
    >the free store. Is this correct?


    It depends on your library implementation.

    Do cache by default:
    SGI, STLport, libcomo, libstdc++
    Don't cache by default:
    Dinkumware (without LibCoreX)

    I don't know about others, but I suspect that most others do provide
    caching by default.

    >2) It appears that the same is the case with the "normal" memory allocator
    >(which we've been calling the 'glibc' memory allocator; is this a misnomer).
    >Memory that has been released from the program with the 'delete' statement
    >is available to other calls to 'new' but not to memory being allocated by by
    >the STL memory allocator. Is this right?


    I don't think so. "delete"d memory should be available to the STL.

    >The conclusion here seems to be that a program that allocates large chunks
    >of memory using both the STL allocator and glibc allocator is doomed to be
    >quite memory-inefficient. If avoiding the usage of both of these allocators
    >is impossible in our program, what hope do we have?


    The STL allocator should be an allocator built on top of the normal
    C++ allocator - ultimately it should use ::eek:perator new and ::eek:perator
    delete to allocate and deallocate memory, although it will manage its
    own pools of memory from those sources.

    In any case, most libraries that have a caching STL allocator allow
    disabling of the caching. e.g. for GCC and libstdc++, try reading
    this:

    http://gcc.gnu.org/onlinedocs/libstdc /ext/howto.html#3

    Tom

    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Jan 30, 2004
    #2
    1. Advertising

  3. "tom_usenet" <> wrote in message
    news:...
    > I don't think so. "delete"d memory should be available to the STL.


    Our experiments say otherwise. We can 'delete' memory allocated with 'new'
    (large arrays of characters) and then fill large vector<int> objects and
    notice that none of the memory is reclaimed.

    Scott
     
    Scott Brady Drummonds, Jan 30, 2004
    #3
  4. Scott Brady Drummonds wrote:
    > "tom_usenet" <> wrote in message
    > news:...
    >
    >>I don't think so. "delete"d memory should be available to the STL.

    >
    >
    > Our experiments say otherwise. We can 'delete' memory allocated with 'new'
    > (large arrays of characters) and then fill large vector<int> objects and
    > notice that none of the memory is reclaimed.
    >
    > Scott
    >

    I haven't read the whole thread so I may have missed something. vector
    doesn't free up memory as its size is reduced (i.e. the capcity stays
    the same).

    Take a look here for a solution (Answer to q2):
    http://www.gotw.ca/gotw/054.htm

    Michael Mellor
     
    Michael Mellor, Jan 30, 2004
    #4
  5. "Scott Brady Drummonds" <> wrote in
    message news:bvejgv$eb4$...
    >
    > "tom_usenet" <> wrote in message
    > news:...
    > > I don't think so. "delete"d memory should be available to the STL.

    >
    > Our experiments say otherwise. We can 'delete' memory allocated with

    'new'
    > (large arrays of characters) and then fill large vector<int> objects and
    > notice that none of the memory is reclaimed.


    Many memory allocators try not to use recently freed memory as it is
    generally harder to detect leaks if you do.
     
    Nick Hounsome, Jan 31, 2004
    #5
  6. Scott Brady Drummonds

    tom_usenet Guest

    On Fri, 30 Jan 2004 13:49:17 -0800, "Scott Brady Drummonds"
    <> wrote:

    >
    >"tom_usenet" <> wrote in message
    >news:...
    >> I don't think so. "delete"d memory should be available to the STL.

    >
    >Our experiments say otherwise. We can 'delete' memory allocated with 'new'
    >(large arrays of characters) and then fill large vector<int> objects and
    >notice that none of the memory is reclaimed.


    How are you confirming whether the memory is reclaimed? Your technique
    might be flawed with reference to normal allocators. Try "delete"ing
    the memory and "new"ing increasingly large chunks as a vector might.
    Does it reclaim it then?

    Otherwise, trace into the allocation in the STL and confirm that it
    uses "::eek:perator new" eventually - it should if it is standards
    conforming. If it isn't, like I said, check the docs and it should be
    configurable.

    Tom

    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Feb 2, 2004
    #6
    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. Dan
    Replies:
    0
    Views:
    470
  2. =?ISO-8859-1?Q?Ralf_Schneewei=DF?=

    How to write an allocator for the STL List in VC++ 6.0

    =?ISO-8859-1?Q?Ralf_Schneewei=DF?=, Aug 20, 2003, in forum: C++
    Replies:
    2
    Views:
    607
    Shane Beasley
    Aug 21, 2003
  3. Brian Genisio
    Replies:
    12
    Views:
    8,060
    tom_usenet
    Jan 15, 2004
  4. Mark P
    Replies:
    3
    Views:
    475
    Victor Bazarov
    Apr 5, 2005
  5. Mark P
    Replies:
    1
    Views:
    548
    Mark P
    Apr 24, 2005
Loading...

Share This Page