Re: Memory tracking in GJS

[Ryan Lortie <desrt desrt ca>]

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