Re: Memory tracking in GJS

[Andy Wingo <wingo pobox com>]

On Sun 02 Mar 2014 22:39, Colin Walters <walters verbum org> writes:

> On Sun, Mar 2, 2014 at 3:37 PM, Andy Wingo <wingo 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/