Hi all, The state of garbage collection for typical GTK/JS applications is pretty sad these days. mozjs will execute a garbage collection run when it thinks around 30MB of allocations have been done. The problem is that for a native GObject wrapped into a JSObject there are effectively two sets of allocations: those internal to GObject and those needed to wrap it into a JSObject. While in the latter case the garbage collector will keep track of those segments, we currently never forward the GObject allocations/payload size to the garbage collector. The result is that, especially with large objects (e.g. pixbufs, cairo surfaces, ...) there's a huge difference between what mozjs thinks is the memory situation and the reality, and an application can effectively run out of system memory before the garbage collector kicks in. Firefox gets away with it because JS code only needs to allocate memory outside of the garbage collector very rarely, and those cases are handled internally by manually updating the counter.
Some ideas that have been floating around: * have special methods on "interesting" objects to explicitly release memory. gnome-shell for instance does this already when using Cairo from within JS, for exactly the same reason. * override the GLib memory allocator with e.g. g_mem_set_vtable() to intercept allocations and signal the garbage collector. Problems: doesn't work for things that use e.g. static constructors, is tricky for re-entrancy, libraries like GdkPixbuf might not use the GLib allocator for image payloads, doesn't work with the slice allocator. * override/intercept allocations with a LD_PRELOAD hack. Pretty evil and brittle. * keep track of memory allocated in GJS itself. We can use GType to query the size of the instance, class and even the size of private data. This still doesn't include additional allocations inside the object itself, such as strings, buffers and payloads. We could track those case-by-case by e.g. overriding constructors in the binding for "interesting" pixbuf-like types (ugh), or have a way to query that information from the type system/introspection itself. Any other ideas? I feel this is a fundamental enough issue that there must be a good way to design a generic solution. Cheers, Cosimo
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
