Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

array unset memory unreleased ?

52 views
Skip to first unread message

Luc Moulinier

unread,
Mar 10, 2017, 9:51:27 AM3/10/17
to
Hello,

I'm wondering if there is a problem with memory releasing in "array unset". The example below shows that ~130 Mb are still allocated after [array unset].
This is a real problem for me. I run a threaded app, and the memory gets increased by 50 Mb for each job done, although I unset/array unset ALL variables. As I have 3000 jobs to do, the computer memory crashes...

Is this a bug ?
Thanks !

Luc


ena_Agents_> ~/tcl8.6.4/luinst/bin/tclsh
% memory info
total mallocs 28562
total frees 20271
current packets allocated 8291
current bytes allocated 468387
maximum packets allocated 8478
maximum bytes allocated 486780

% for {set i 0} {$i < 1000} {incr i} {
for {set j 0} {$j < 1000} {incr j} {
for {set k 0} {$k < 10} {incr k} {
set T($i,$j,$k) [list $i $j $k]
}
}
}
% memory info
total mallocs 177036569
total frees 47028199
current packets allocated 130008370
current bytes allocated 4687928171
maximum packets allocated 130008401
maximum bytes allocated 4687931240

% array unset T *
% unset T
% update
% memory info
total mallocs 177037648
total frees 177029206
current packets allocated 8442
current bytes allocated 134684863
maximum packets allocated 130008437
maximum bytes allocated 4687932230

% exit

Rich

unread,
Mar 10, 2017, 9:58:31 AM3/10/17
to
Luc Moulinier <luc.mo...@igbmc.fr> wrote:
> Hello,
>
> I'm wondering if there is a problem with memory releasing in "array
> unset". The example below shows that ~130 Mb are still allocated
> after [array unset]. This is a real problem for me. I run a
> threaded app, and the memory gets increased by 50 Mb for each job
> done, although I unset/array unset ALL variables. As I have 3000
> jobs to do, the computer memory crashes...
>
> Is this a bug ?

Not likely. Tcl follows the traditional C style that once it requests
memory from the OS when that memory is freed it is held by the process
to be reallocated from later instead of asking the OS for more memory.
The reason is that traditionally the OS system call for
allocating/freeing memory is significantly slower than allocating from
a pool that the process already owns.

So what you are probably seeing is that while the memory is "free" for
Tcl and avaialble to be reused by the Tcl process, it is not returned
to the OS itself.

The real indicator of a problem is if your memory usage continues to
climb rather than reaching some plateau where it levels off.

Luc Moulinier

unread,
Mar 10, 2017, 11:19:23 AM3/10/17
to
>
> The real indicator of a problem is if your memory usage continues to
> climb rather than reaching some plateau where it levels off.

This is what is happening when I send my jobs ! If I understand well, the most memory a thread will use is the memory allocated by the biggest job done in this thread. In my case, the memory increases by ~50Mb each time a job is processed by a thread. I carefully checked all my variables/arrays are unset (comaring info globals betwenn enter/return of job).

So , if the process is not re-using the memory it allocates in previous allocations, ... there is nothing to do at Tcl level ?

Thanks for your explanation !!!
Luc

Rich

unread,
Mar 10, 2017, 12:22:07 PM3/10/17
to
One more thought. Are you using thread shared variables in any way?

If yes, have you also checked that you are also cleaning those up when
done with a job?

0 new messages