Re: gm RES memory problem

On Sat, 8 Dec 2018, yzh卯帽潞锚 wrote:
>
> I simply read a gif image and destroy it, and the RES memory is finally stabilized at 172476 when sleep.
>
> This is not a memory leak, when I call it in a for loop, the memory just fluctuate at this level. It is likely something has been cached.
>
> So I want to know what does GM do and why.

What you are seeing is almost certainly due to the normal operation of 
the C language "heap", which is where memory allocated by malloc(), 
calloc(), and realloc() comes from.

> My GM versin is 1.3.29 and system is Centos7.1

In Linux there are two ways to allocate memory using the normal heap 
memory allocator (e.g. malloc).  The traditional way is that the 
process address size is adjusted using the brk() or sbrk() system call 
to provide the process with more memory address space, and then memory 
is allocated from this space and returned to the application.  While 
it is possible to reduce the process address space, this is difficult 
for the traditional "heap" because some intermediate allocations may 
remain and it is not possible to move those allocations because the 
addresses (numbers) are still used by the application.  The 
traditional heap can be very fast to allocate memory and it does 
recycle memory (as a cache) when memory is released by the program 
because programs often allocate/deallocate very often.

The alternate way to allocate memory is to use mmap() and this way 
does allow the program to easily give back memory to the operating 
system.  With Linux glibc large memory allocations usually are based 
on mmap() but smaller allocations use the traditional heap.

Under Linux, you can investigate the memory used by the still-running 
application by reading the content of /proc/PID/smaps, where PID is 
the current process id of the program.  This "file" is just a text 
file so you can obtain its content using 'cat /proc/PID/smaps'. 
There is a special case where PID can be replaced with 'self' 
(/proc/self/smaps) rather than a number, so the program can 
investigate its own usage.

There are things that you can do to influence malloc.  Please read the 
Linux manual page for mallopt() ('man 3 mallopt') and malloc() 
('man 3 malloc') you will see that there are environment variables, 
and mallopt() options which you can use to tune how the heap allocator 
works.

With recent glibc, I see that mallopt supports M_TRIM_THRESHOLD, which 
sets a threshold where the allocator will try to release traditional 
heap address space back to the system, possibly reducing the memory 
retention that you are seeing.  The manual page I am currently reading 
says the default threshold is 128*1024, which is not far from the 
172476 value you are seeing.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help