949218 - Allow counting js objects by registering the contract id to assess memory usage

Status: NEW

(Core :: XPCOM, defect)

Description

[Philipp Kewisch [:Fallen][📱📆]]

I would like to improve memory usage in my extension which is mostly JS based. It would be helpful if there was a way to make creating JS xpcom objects count towards a specific memory reporter, to figure out how many of them are alive.

My first hint was to use a custom counter, but there is no way to find out when the object is GC'd. So I was thinking it might be possible to do this by registering the contract id with the memory reporter manager and let xpconnect/xpcom handle the counting.

Comment 1

[Nicholas Nethercote [inactive]]

This sounds like a quite specific solution for a general problem, and I think it would be helpful to step back for a minute. Can you describe in a bit more detail exactly what information you would like to have, without making any assumptions about how to get that information? Thanks!

Also, this reminds me a bit of bug 932156.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

Going for a specific use case now. I would like to use this for Lightning, the calendaring extension for Thunderbird. We have historically built everything upon xpcom and for example an event is described by a Javascript-based component with contractid "@mozilla.org/calendar/event;1".

Our memory usage is quite high and I'm assuming part of the problem is that this event component is clonable and is being cloned happily in various places, without there being a need for it. I also wouldn't be surprised if certain operations leak event objects.

So what I would like to do is at least count the active event objects and see how certain operations increase the object count and if all objects are cleared after a further operation where you would expect the events to go out of context, plus a forced GC.

I believe at the time I filed this bug there wasn't any movement in bug 932156 and it sounded very hard to do currently. I might have misunderstood, but from our IRC conversation I understood that this approach might be easier to complete. If bug 932156 will cover my use case, thats fine with me too.

Comment 3

[Till Schneidereit [:till]]

This sounds like it might be better served by developer tools built on top of the allocation site tracking introduced in bug 850026.

Roughly, we will at some point be able to compare heap snapshots and, for each object that exists in the second, but not the first snapshot, say where it was allocated. And what keeps it alive.

CCing some devtools people, too.

Comment 4

[Nicholas Nethercote [inactive]]

Yeah, this is very specific to people writing extensions. jimb said he might be able to generalize the idea.

Comment 5

[Jim Blandy :jimb]

I filed bug 962316. We're going to have a "census" primitive that categorizes all the nodes it encounters in various ways; this seems like another reasonable axis to consider implementing, perhaps enabled only for chrome debugging.