slice allocator misuse?

[Benedikt Meurer]

Brian J. Tarricone wrote:
>>> * Use g_slice_* functions when available at compile time.
> 
> Why are we going nuts about the slice allocator?  From the glib docs:
> 
> "Memory slices provide a space-efficient and multi-processing scalable
> way to allocate equal-sized pieces of memory, just like the original
> GMemChunks (from GLib <= 2.8), while avoiding their excessive
> memory-waste, scalability and performance problems."
> 
> This makes sense for some things, like allocating arrays that need to
> grow and shrink (actually maybe not even here), or repeated alloc/free
> in a loop, or lots of instances of the same struct, etc.  But why for
> things like one-time dialog structs, etc.?  I guess the questions is: is
> a single g_slice_alloc() faster than a single g_malloc()?  If not, some
> of these 'use the slice allocator' patches are seriously misusing it...

No. g_slice_alloc() is not necessarily faster than malloc(), atleast
with some malloc() implementations. But the advantage of g_slice_alloc()
is that memory is garantied to be aligned at sizeof(void*) boundaries
and no additional memory is allocated to store the size of the chunk,
which is a problem with several malloc() implementations. This can make
a different for example in ExoIconView, where we need 4-8 bytes fewer
per ExoIconViewItem when using g_slice_alloc() instead of malloc() (not
that we ever used malloc() there, but GMemChunk is no longer usable as
such with 2.10). Same for ThunarVfsPath's, etc.

Probably the main disadvantage of the slice allocator is that memory is
not returned to the kernel with malloc() implementations that would
otherwise do this (i.e. the FreeBSD implementation). This would help to
avoid swapping in low-memory/high-load situations, but is not necessary
important for desktops, but way more important for servers. For other
malloc() implementations this doesn't make a difference, since malloc()
will never return memory to the kernel anyway.

To conclude: The slice allocator should be preferred in nearly all
situations where the exact size of the object is known at allocation and
destruction time (for example this is also used unconditionally by
g_type_create_instance() now). The more structures using the slice
allocator, the less fragmentation between memory allocated to the
magazines using malloc()/valloc()/posix_memalign() and malloc()'s own
tables, i.e. the less wasted memory. However the slice allocator comes
at a certain price: Most malloc() implementations are usually able to
ignore or even correct invalid free()'s, or atleast crash in these
situations. The slice allocator in GLib is pretty stupid there and
you'll see crashes at a later time, which are hard to recognize. Once
recognized, you can use G_SLICE=always-malloc and set MALLOC_OPTIONS (or
_MALLOC_CHECK) appropriatly.

> 	-brian

Benedikt