Re: GSlice with tight memory (Re: Help Needed)

[Tim Janik <timj imendio com>]

On Wed, 23 Aug 2006, Kaustubh Atrawalkar wrote:

> Soeren Sandmann wrote:

> > Tim Janik <timj imendio com> writes:
> > > whether you benefit in terms of memory size by using GSlice instead of
> > > malloc/free depends heavily on your application. simply watch your
> > > memory requirements with G_SLICE=always-malloc and without it.

> > In general, I'd recommend just always using
> >
> >         g_slice_set_config (G_SLICE_CONFIG_ALWAYS_MALLOC, 1);

> > Soren

> I have already tested g_slice_set_config for always malloc and also for 
> disabling magazine layer.

using just the slab allocator without the magazine layer is a bad idea, 
read note [2] in glib/glib/gslice.c if you want the details.

unfortunately, Soeren has been giving you very bad advice here (and for
bogus reasons), usually applications or libraries shouldn't use
g_slice_set_config() at all, it's meant as debugging API and declared
internal, because there is not much that could reasonably be tuned about
the allocator through this interface anyway.

> This helps me in my application. But the major 
> problem is application development is not in my hand. This will be done by 
> the third party which will be using the normal glib wrappers without knowing 
> the underline memory management. I m porting the glib on an embedded arm 
> architecture where my cache is also very small. So the allocation done by 
> slab allocator wont be much effective cause the size of the chunk will be 
> fixed may be its 100k app or 1Mb app.
>
> Can i implement something like dynamic slab allocator? in which i can vary 
> the chunk/slab size depending upon the application requirment using some 
> mechanism like memory pressure??

adding an extra function to GSlice to sweep all caches for memory pressure
scenarios is on my TODO list.
it doesn't have the highest priority though, because linux is lacking something
like a SIGLOMEM, but glib will eventually have it.

---
ciaoTJ