Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place.
I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and reuse allocations.
It’s also a major security risk, since it nullifies hardening measures from the standard library, as we have seen with openssl/heartbleed recently.
> these days there is no reason to cache and reuse allocations.
No, you are wrong. Ideas like that are a big reason that apps get slower despite hardware getting faster.
Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?
Yup [0].
There's even other complete libraries like tcmalloc [1] and jemalloc [2].
[0] https://stackoverflow.com/a/262481/1111557