memory allocations for libraries used by libvirt

[Daniel P. Berrangé]

On Wed, May 19, 2021 at 10:30:30PM +0200, Olaf Hering wrote:
> Currently src/libxl/ allocates a bunch of buffers with variants of g_new0() or g_strdup(), which will be consumed by libxenlight.so. Once the objects which contain these buffers are not needed anymore, libxenlight.so will release them with ordinary calls to free() in its *_dispose() API. In other words: libxenlight.so does not use glib.
> 
> While the g_malloc docs of today's glib state that (apparently) the mistake of using a private allocator was recognized and corrected in glib 2.46, the same mistake might occur again in the future.

GLib used to have APIs that let you inject a custom malloc impl.

They deprecated and then removed the impl for this, and hardcoded
GLib to always use the system malloc. IIUC the main reason for this
was the increasing use of __constructor__ functions in libraries.
It is not practical to have something in main() which configures a
replacement malloc impl, because by that point many GLib functions
will have already been called using the system malloc.

IOW, if you want to replace the system malloc you need to do it
process-wide by explicitly linking to a library that overrides
the standard C library malloc() APIs.

When libvirt adopted glib, I confirmed the long term plans with
GLib maintainers and got them to add a docs note to make this
explicit:

  "Since GLib 2.46 g_malloc() is hardcoded to always use
   the system malloc implementation."

https://developer.gnome.org/glib/2.64/glib-Memory-Allocation.html

So, there's no need to worry about free/g_free, they are guaranteed
identical.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|