[...]
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-Sli...
"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@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel