hi, On Thu, Feb 20, 2014, at 7:53, Giovanni Campagna wrote: > It's worth pointing out that mozjs will *force* a garbage collect if > you go over the malloc limit (a dynamic value between 30 and 90 MB), > but will garbage collect a lot more often if you call MaybeGC.
My preferred solution to the problem involves doing this, perhaps from a very low priority idle, once the mainloop has stopped spinning. I think any proposal that involves a sort of 'information API' where 'well behaved' classes are supposed to provide memory usage information is probably going to be very burdensome. Just to explore an example, a bit: let's say that we really strictly wanted to limit our scope and apply this logic *only* to pixbufs, because we identified those to be a problematic area. We now either need to do one of two things: - keep track of all pixbuf allocations in the program so that gjs can query a list and use this information to decide to do more GC - wire this interface through to the public API of any object that holds a pixbuf within itself, and through to the APIs of objects that hold those objects (etc.) in order to make this information visible on the actual objects held by gjs I consider the first alternative to be excessively evil. It's also unlikely to be able to give you the information you really need -- sure, we have 100MB of pixbufs allocated, but they might be in places that GC wouldn't help you. The second alternative is just entirely too much work to expect of every class that might stand between a pixbuf and a public API -- and we've only limited our scope to pixbufs already. It's also problematic from a (perhaps pedantic) accounting standpoint: if two objects reference a shared pixbuf (or intermediate object) then who gets to claim the memory use as their own? The other allocation-based alternatives sound like possibilities, but perhaps are very much too brittle. For what it's worth, I'm happy to try to find a way to make disabling the slice allocator and adding a memory vtable possible again... Is Giovanni's proposal workable? Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list