C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  STL v. Norma" Memory Allocator          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message Scott Brady Drummonds Guest Posted: Fri Jan 30, 2004 5:02 pm    Post subject: STL v. Norma" Memory Allocator 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. Back to top tom_usenet Guest Posted: Fri Jan 30, 2004 6:15 pm    Post subject: Re: STL v. Norma" Memory Allocator On Fri, 30 Jan 2004 09:02:09 -0800, "Scott Brady Drummonds" <scott.b.drummonds.nospam (AT) intel (DOT) com> wrote: Quote: 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. Quote: 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. Quote: 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 ::operator new and ::operator 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 Back to top Scott Brady Drummonds Guest Posted: Fri Jan 30, 2004 9:49 pm    Post subject: Re: STL v. Norma" Memory Allocator "tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote Quote: 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 Back to top Michael Mellor Guest Posted: Fri Jan 30, 2004 10:10 pm    Post subject: Re: STL v. Norma" Memory Allocator Scott Brady Drummonds wrote: Quote: "tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote in message news:f16l10ptg6l0h8vpjdg6m9v6d2pc19egui (AT) 4ax (DOT) com... 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 Back to top Nick Hounsome Guest Posted: Sat Jan 31, 2004 7:16 pm    Post subject: Re: STL v. Norma" Memory Allocator "Scott Brady Drummonds" <scott.b.drummonds.nospam (AT) intel (DOT) com> wrote in message news:bvejgv$eb4$1 (AT) news01 (DOT) intel.com... Quote: "tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote in message news:f16l10ptg6l0h8vpjdg6m9v6d2pc19egui (AT) 4ax (DOT) com... 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. Back to top tom_usenet Guest Posted: Mon Feb 02, 2004 9:42 am    Post subject: Re: STL v. Norma" Memory Allocator On Fri, 30 Jan 2004 13:49:17 -0800, "Scott Brady Drummonds" <scott.b.drummonds.nospam (AT) intel (DOT) com> wrote: Quote: "tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote in message news:f16l10ptg6l0h8vpjdg6m9v6d2pc19egui (AT) 4ax (DOT) com... 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 "::operator 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 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.