Re: memory profiling (was calling g_malloc & co via a vtable)

[Tim Janik <timj gtk org>]

On 4 Oct 2000, Havoc Pennington wrote:

> > What do the Gtk+ maintainers think about a policy where we provide the
> > additional code to free these data structures on exit, using g_atexit? I'd
> > be happy to supply patches for this as well at some point.
> > 
> 
> Tim was strongly opposed at one point. Owen and I were thinking about
> it.

i'm still strongly opposed to this. the reasons for this are:
1) it is a PAIN to get right
2) it will make code way more complex in some places where we do know
   we want static allocations (gtype.c gsignal.c) and code got way simpler
   when it didn't have to care about deallocations
3) the huge amount of work involved only has minor benefits, that is if
   reliable profiling data is required which is not the common usage case
   for our libraries. also, because of 1), it'll be extremely frequently
   buggy, thus the exact profiling figures will seldomly be reliable
4) it's going to be a long-term maintenance nightmare, see 1)
5) this is a minor but ugly point: people may try something like:
   gtk_init(); [...] gtk_uninit(); gtk_init();
   and then expect it to work (for those that don't believe me, we already
   had reports where people actually used gtk_signal_handlers_destroy() in
   their code)

that said, i do buy into the idea of using a reliable memory profiler, the
solution to let the (internal) profiler know about allocations that are
meant to be static is to provide g_malloc(), g_new(), g_malloc0(), g_new0()
g_renew() and g_realloc() variants for static data. those would be added to
GMemVTable and be used by a profiler that installs his own memory allocation
functions (could also simply be a boolean flag for the existing functions in
the table).

going throughout GLib/Gtk code and doing s/g_malloc()/g_static_malloc()/ where
apropriate is less than 1% of the work required for 1), especially long-term
and it will work much more reliable.

the downside of this is, that owen was opposed to it because of increased
API complexity.

> 
> Havoc
> 

---
ciaoTJ