[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Memory tracking in GJS
From:       Andy Wingo <wingo () pobox ! com>
Date:       2014-03-03 9:02:16
Message-ID: 8761nvr6xz.fsf () pobox ! com
[Download RAW message or body]

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/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]