Memory Profiler for Firebug
Jan Odvarko
is currently based on work made by Atul Varma and Dion Almaer. See
e.g. here:
https://wiki.mozilla.org/Labs/Jetpack/Memory_Profiling_Notes_from_July_2009
You can see some results here: http://getfirebug.com/wiki/index.php/Firebug_Memory_Profiler
(it's based on C++ APIs from Jetpack, not the SDK).
The question here is related to two main problems that I have faced
during the implementation.
- There is no way how to get precise size (row bytes) information for
e.g. strings, which would be nice addition to some size info already
provided. Some other more structured size info (related to images,
HTML elements, etc) would be also useful.
- The other thing is related to JS objects identification. The memory
profiler API (specifically the nsIJetpack.profileMemory method)
returns all the meta info about JS objects (being currently in the
Firefox runtime) marked with unique IDs. When displaying all the info
in Firebug UI, it's useful to associated these meta-data with real
objects on the page (and e.g. get real names). So, the user can
understand all the size and e.g. referents info. The problem is that
there is no way how to get JS object ID and/or to get an existing JS
object according to the ID (I know that JSD provides an APIs to get
these IDs for script objects: jsdIScript.tag).
The workaround I have found is to pass all JS objects into the
memoryProfiler methods (as named objects) and get appropriate IDs
within results. But this is time expensive since all existing JS
objects on the page must be iterated...
Would it be feasible to implement such APIs in the JSD layer?
Are there any related bugs reported I could follow or should I report
bugs for this to kick off a further discussion about new APIs that
would help to profile web page memory consumption? This is one of the
most requested feature in Firebug community.
Thanks!
Honza
Ted Mielczarek
Jason Orendorff and Julian Seward have been discussing something
similar in bug 551477, perhaps you should talk to them?
-Ted
Jan Odvarko
I'll follow the discussion under the bug.
Honza
johnjbarton
> I have been recently working on a memory profiler for Firebug, which
> is currently based on work made by Atul Varma and Dion Almaer. See
> e.g. here:
> https://wiki.mozilla.org/Labs/Jetpack/Memory_Profiling_Notes_from_July_2009
>
> You can see some results here: http://getfirebug.com/wiki/index.php/Firebug_Memory_Profiler
> (it's based on C++ APIs from Jetpack, not the SDK).
>
> - The other thing is related to JS objects identification. The memory
> profiler API (specifically the nsIJetpack.profileMemory method)
> returns all the meta info about JS objects (being currently in the
> Firefox runtime) marked with unique IDs. When displaying all the info
> in Firebug UI, it's useful to associated these meta-data with real
> objects on the page (and e.g. get real names). So, the user can
> understand all the size and e.g. referents info. The problem is that
> there is no way how to get JS object ID and/or to get an existing JS
> object according to the ID (I know that JSD provides an APIs to get
> these IDs for script objects: jsdIScript.tag).
>
> The workaround I have found is to pass all JS objects into the
> memoryProfiler methods (as named objects) and get appropriate IDs
> within results. But this is time expensive since all existing JS
> objects on the page must be iterated...
But if you want the meta-data for a single object, you only need to pass
the single object to the memoryProfiler correct?
>
> Would it be feasible to implement such APIs in the JSD layer?
I think we can do this with jsd_GetJSDObjectForJSObject:
http://mxr.mozilla.org/mozilla1.9.2/source/js/jsd/jsd_obj.c#315
but I think you would be disappointed with the results. A jsdIObject
allows you to (in theory!) find the line of code where the object was
created. But mostly I think developers want to know "what properties of
what objects point to this object".
For that we need a symbolic "path" to objects. For objects rooted in
|window|, we have "window.foo.bar" as a path. If no JS is running, are
there any other objects? I guess yes, those bound into closures. How can
we see them and what would a path for these objects look like?
jjb
Jean-Marc Desperrier
> mostly I think developers want to know "what properties of what objects
> point to this object".
But the garbage collector also needs to know that ?
Boris Zbarsky
Generally speaking, no. All it needs to know is "is there any reachable
object that has a property pointing to this object?" It does NOT need
an exhaustive list of such object/property pairs, for sure.
-Boris
Mike Shaver
> Generally speaking, no. All it needs to know is "is there any reachable
> object that has a property pointing to this object?" It does NOT need an
> exhaustive list of such object/property pairs, for sure.
I think it sees all of them, though. (A copying collector would need
to, in order to update pointers, but I don't think that's anything
special about the mark phase vs what we do now.)
Mike
johnjbarton
The memory profiler uses the same data structure as the garbage
collector. It is able to answer the question "what addresses have
pointers to the address of this object"? and "what are the addresses of
these given objects"? (The profiler calls the addresses "ids"). So
Honza's problem has two parts:
1) Creating the list of given objects takes a lot of time in JS code,
2) Our JS code cannot reach all of the objects (because some are in
closures) so we can't put them on the given-objects list.
I believe that if we could solve the second one we could create a tool
that would be useful for exploring the object graph. (It's still
doubtful that the tool would help with memory problems, but that is a
separate problem).
jjb