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

[Lex Trotman]

[...]
>> 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.

Sure using gslice will help but, as you say below, its unlikely to be
worth the effort just for this purpose, doing it for speed and other
reasons might be useful but thats another discussion.

1. gslice is good when you allocate lots of things the same size, and
you know the size, since that must be supplied to slice_free, but a
large portion of our allocations are strings, so we don't remember the
size (see for eg tagmanager).

2. Even if all of Geany used gslice, libc still uses system malloc so
we can't get rid of it (and we need to be careful not to mix these
memories)

3. Scintilla still uses the C++ allocator, which isn't malloc/free
(IIUC its what is sometimes called a SLUB allocator mixed with a Lea
allocator, ie a cross between g_slice and malloc)

>
> 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."

Yes, it waits 15 seconds before freeing empty slabs back to the
system, thats what I mean by "each of which has differing policies for
holding onto memory".  This is actually observable, but it only frees
about 100k of the 28Mb.  malloc and C++ work differently.

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

No, even the glib developers don't claim it completely prevents
fragmentation :)  It completely prevents *internal* fragmentation
within a slab since all chunks are the same size, but no slab can be
returned to the system or re-used for another size if it has any
chunks still in use.  And this form of fragmentation is very likely
since Geany and GTK and tagmanager etc all hold on to random bits of
memory (because they need to, its not a bug), thus blocking release of
slabs.

>
> 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.

Agree, I don't think we are going to be able to totally cure the
"problem" but we can waste lots of effort on it.

@Colomban, g_slice benefits come from allocating the same *size*
structures, they don't need to be the same structure, but its much
harder to analyse since strings are all sorts of sizes.

Cheers
Lex


> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>