Thanks to:
Fergus Donohue <Fergus.Donohue_at_dcu.ie>
who pointed out that he had solved those problems with GNU version of
malloc library.
Robert Mulley <robert_at_gnsconsulting.com.au>
"Dr. Tom Blinn, 603-884-0646" <tpb_at_doctor.zk3.dec.com>
Both pointed out something that should have been obvious to me, malloc
is using "sbrk()" system call to increase address space of the process.
In order to make things more efficient, "free()" is no longer returning
the memory it claimed in "malloc()", in case there is another "malloc()"
afterwards.
This is a feature, not a bug, we have to live with it.
There could be engineered hypothetical situations where this feature
would be unwanted, in my opinion. Take a process that has several
instances running and that has light-weight memory usage, but
occasionally has an excessive memory allocation. After a while all of
those processes will have their memory space size nailed to their MAX,
with no apparent need. Of course this can be avoided in anumber of ways
(manually reclaim memory, have those processes live shorter, etc.).
I guess the news is not really that disturbing, but I believe it ca
cause problems. Fergus reported he had to switch to GNU malloc because
SQUID was running out memory.
Thanks to all who replied.
Nix.
--
... You have the right to remain silent. USE IT!
Received on Fri Nov 17 2000 - 14:47:05 NZDT