[Geany-devel] Geany memory behavior "suspected memory leak - ID: 3415254" - g_slice
nick.treleaven at xxxxx
Mon Oct 17 12:40:09 UTC 2011
On 15/10/2011 00:08, Lex Trotman wrote:
> 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).
Yes, by fixed size alloc I meant fixed size types, not strings.
>> Secondly, see:
>> "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
Yep, this is a problem.
>> 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
> 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.
Actually it probably depends on the context as to whether g_slice is a
More information about the Devel