hi scott,
Thanks for the reply. I agree with you. The problem that i have with this approach is that the memory consumption grow a lot after some time of processing. i.e. when i allocate X amount of memory, after calling delete, that chunk may be added to a reuse list and reused if the next allocation is X or smaller than X. But when i allocate X, then delete and allocate another chunk Y > X, the memory consumed by the process is not X + Y, is bigger than that ( don't know why ). This, after some time of processing, make my process memory consumption grow a lot ( GB of memory allocated ).
After some testing, i found that the string STL implementation, deallocate the memory right after calling delete. This solves my problem. At first i wasn't going to use string because i need perfomance. But know i have no options left. Also, i found that the performance is not so bad after some tests I run.
Here is the similar code i posted before, but using string
#include <iostream>#include <string>using namespace std;
int main(){
string *str;
sleep(10);
str = new string[100000]; for(int i = 0; i < 100000; i++) { str[i] = "prueba1"; }
sleep(20);
delete [] str;
sleep(10);
}
Thanks to all for the help
Regards
To: c400-l@xxxxxxxxxxxx
From: sphanson@xxxxxxxxxx
Date: Mon, 21 May 2012 09:44:41 -0500
Subject: Re: [C400-L] memory deallocation with delete
Hi Victor,
I believe what you are seeing is a result of the implementation of the ILE
teraspace heap memory manager. At the point of the delete [] call, the
heap memory manager is not calling the operating system to actually free
the memory, but is instead adding the allocated memory to a reuse list. It
is doing this in anticipation that the memory will be reused at a later
point in the application. In general, this provides much better
performance than calling the operating system to allocate and free every
chunk of memory. The algorithm to determine how much memory is in the
reuse list is rather difficult to explain, but for the purposes of your
sample program, a maximum of ten allocations will be kept on the reuse
list. Once the reuse list is 'full' with the ten allocations, each delete
[] will call the operating system to actually free the memory. In all
cases, the memory will always be deallocated when the application ends.
There is no way to modify this behavior of the teraspace heap memory
manager. The specific reuse list algorithm can (and does) change slightly
from release to release.
FWIW, the _C_TS_malloc_info() function can be used to determine the exact
amount of teraspace heap memory allocated at any given point in time. This
may be of use to you in tracking down the memory leak. The documentation
for that function is available at
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frtref%2Fctsmallocinfo.htm
Scott Hanson
From: Victor Gonzalez <victorpy@xxxxxxxxxxx>
To: <c400-l@xxxxxxxxxxxx>
Date: 05/18/2012 02:55 PM
Subject: [C400-L] memory deallocation with delete
Sent by: c400-l-bounces@xxxxxxxxxxxx
hello everyone,
Trying to debug a memory leak in a program, written in C++ and compiled
with ILE C++ compiler, i found an odd behavior with the temporary memory
allocation in the AS400.when i run the following piece of code:
int main(){
char *test;
sleep(10);
test = new char[20000000]; for(int i = 0; i < 20000000; i++)
{
test[i] = 'a'; }
sleep(10);
delete [] test; test = NULL; //q->PrintElements();
sleep(5);
}
i found that the temporary storage used is not released after the calling
"delete". The temporary storage used i use, is the one that could be seen
with the command DSPJOBD
In other test's if found that after allocating other kind of objects,
calling the delete operator immediately release the memory previously
allocated.
For compilation i use STDMDL *teraspace. The rest of the options are the
default
Any "enlightenment" about this behavior will be welcome
Thanks in advance.
--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/c400-l.
midrange.com
