STL v. Norma" Memory Allocator

[Scott Brady Drummonds]

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.

[tom_usenet]

On Fri, 30 Jan 2004 09:02:09 -0800, "Scott Brady Drummonds"
<sc************ **********@inte l.com> 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 ::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/libstd...t/howto.html#3

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Scott Brady Drummonds]

"tom_usenet " <to********@hot mail.com> wrote in message
news:f1******** *************** *********@4ax.c om...

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

[Michael Mellor]

Scott Brady Drummonds wrote:

"tom_usenet " <to********@hot mail.com> wrote in message
news:f1******** *************** *********@4ax.c om...

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

[Nick Hounsome]

"Scott Brady Drummonds" <sc************ **********@inte l.com> wrote in
message news:bv******** **@news01.intel .com...

"tom_usenet " <to********@hot mail.com> wrote in message
news:f1******** *************** *********@4ax.c om...

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.

[tom_usenet]

On Fri, 30 Jan 2004 13:49:17 -0800, "Scott Brady Drummonds"
<sc************ **********@inte l.com> wrote:

"tom_usenet " <to********@hot mail.com> wrote in message
news:f1******* *************** **********@4ax. 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