On Sun 02 Mar 2014 22:39, Colin Walters <walt...@verbum.org> writes: > On Sun, Mar 2, 2014 at 3:37 PM, Andy Wingo <wi...@pobox.com> wrote: > > Ideally GLib could define an interface void g_register_allocation > (size_t bytes, char *for_whom); > > What about GLib libraries which wrap non-GLib libraries that do the > heavy lifting? For example, the gjs wrappers for cairo.
You just have to guess :/ In the case of cairo you can estimate based on surface size and configured bit depth. Guessing is fine in this case. > I think we're still going to need a multi-pronged approach, with an > explicit dispose API, running large allocations through an API like the > one you proposed, as well as kernel level support for hints about a good > time to GC (and how much time to spend doing so). Could be, yes. Kernel support probably makes more sense with a moving GC, which is part of upstream SM but not enabled yet. Otherwise a GC could see reports of memory consumption Y, from the kernel's perspective, but really a GC can't do anything about it because of fragmentation. Anyway, unfortunately I don't have time to help at the moment. I'm happy to chat about these things though if you need someone to bounce ideas off. Cheers, Andy -- http://wingolog.org/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
