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

[Kaustubh Atrawalkar <kaustubh atrawalkar celunite com>]

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);
>
> This way the various tools, valgrind and memprof, will work with your
> application, and you don't get any surprises with pathological cases
> causing run-away caching. The speed difference between g_slice and
> g_malloc is basically noise as soon as you include the time to
> initialize the new block of memory.
>   

> If it does turn out that malloc() shows up on a profile (either memory
> or speed), those specific cases can be fixed. With application
> knowledge you can do a better job than any general purpose allocator.
>
>
> Soren
>   
I have already tested g_slice_set_config for always malloc and also for 
disabling magazine layer. 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??