[Geany-devel] Geany memory behavior "suspected memory leak - ID: 3415254" - g_slice

[Nick Treleaven]

On 14/10/2011 04:09, Lex Trotman wrote:
> Hi All,
>
> I have been investigating bug report "suspected memory leak - ID:
> 3415254"

http://sourceforge.net/tracker/?func=detail&atid=787791&aid=3415254&group_id=153444

> 1. each time all files are closed only 200k is returned to the OS, but
> since the first open uses 22.8Mb but later ones less, Geany isn't
> leaking all of it, it is being held by the allocators.
>
> 2. ignoring the first open, the amount of extra memory used to open
> all the files varied from 0.4Mb to 2.9Mb.  Average 1.1Mb or 5% of the
> initial 22.8Mb and standard deviation of 0.665Mb or 3% of the 22.8Mb.
>
> 3. Simple leaks are unlikely to cause the large deviation in the
> memory increase, each open of the same set of files would tend to leak
> the same amount.  It is therefore likely that fragmentation effects
> cause the large deviation, but it may not be the whole cause of the
> increase.
>
> Since Geany uses three different allocators, each of which has
> differing policies for holding onto memory, it is going to be
> difficult to separate real leaks from allocator effects.

Interesting.

I'd like to continue the discussion from the report about allocator usage:

Lex:
"I think probably most of the fragmentation is due to having three
allocators in use, libc, Glib and libc++, and they not sharing or 
returning memory they acquire. This is likely to outweigh the 
cost/benefit of switching to g_slice given the effort required since 
types or sizes are needed in all frees."

Firstly, we already are using g_slice quite a lot - probably the most 
useful place is for allocating TMTag structures. Obviously GLib uses it 
internally.

Secondly, see:
http://developer.gnome.org/glib/2.28/glib-Memory-Slices.html#glib-Memory-Slices.description

"This is accompanied by extra caching logic to keep freed memory around 
for some time before returning it to the system."

Thirdly, GLib recommends using g_slice for fixed size allocations, and 
IIUC g_slice completely prevents fragmentation, besides being faster 
(anecdotally about 2x).

I don't know if converting our other uses of g_new for fixed size 
structures is worth it, but I would say it is good practice to use 
g_slice in all new code.