Created attachment 306206 [details] [review]
Deprecate and drop support for memory vtables

The memory vtables no longer work, because glib contructors are called
before main(), so there is no way to set it them before use. This stops using
the vtable at all, and deprecates and stubs out the related functions.

See also bug 701694

While I mostly support this, I think the assertion is only true for gobject and above.  The libglib.so ctor appears to only parse environment variables and doesn't malloc.

I had been thinking before of allowing applications to
#define GLIB_NO_G_MALLOC
which if set, causes #define g_malloc malloc and so on.

(In practice I assume this in my apps anyways)

But that wouldn't address the indirection inside libg{lib,object,io}.so nor any dependencies.

Also worth noting that e.g. Firefox has been going the other way for https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Memory_reporting
and trying to get statistics at runtime for every allocator type, which relies on library-defined interception.

I'm also in favor of dropping the non-longer working vtable stuff, and instead document g_malloc as always using malloc, and recommend people use libc's profiling support.

Attachment 306206 [details] pushed as 3be6ed6 - Deprecate and drop support for memory vtables