Closed Bug 323075 Opened 19 years ago Closed 13 years ago

JavaScript memory use monitoring extension

Categories

(Core :: XUL, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dbaron, Assigned: dbaron)

References

Details

(Whiteboard: [MemShrink])

I'd like to have an extension for monitoring memory use in JavaScript:  this could help:
 * debug JavaScript-related memory usage problems in chrome and extensions
 * debug JavaScript-related leaks in chrome and extensions
 * debug JavaScript-related leaks related to Web page Javascript
 * make people more aware of all of the above problems.

Information that would be useful to examine could include:
 * some name for each object, perhaps derived from a name associated with its prototype
 * the properties of objects, including __proto__, __parent__
 * what objects an object is reachable from
 * how long an object has been untouched (this requires JS engine hacking)
 * where in the source the object was created (probably requires JS engine hacking)

Views that would be useful to classify the data could include:
 * object allocation location (source code) (requires JS engine hacking, I think)
 * prototype chain
 * parent chain
 * principal (does this differ from parent chain?)
 * scope in which created (does this make any sense?  does it differ from the above?)
 * some tree representation of the reachability graph
Many of these views would probably default to classifying at a top level per global object at the top of the parent chain -- and the global objects could be easily named with (Window / ChromeWindow) and URL.  Probably some view with inner windows inside outer windows would be useful here too.

It would also be useful to be able to sort these views by:
 * number of objects
 * sum over objects of time since the object was last touched
...and the sort would probably need to include descendants for views that are tree-like.

Some of these things are probably a lot easier to implement than others.
Graydon had something like this started, I heard ;-).

/be
 * where in the source the object was created (probably requires JS engine
hacking)
- no hacking required. venkman can already show this to you at times - check the context menu of the locals pane (jsd can record this information).

 * object allocation location (source code) (requires JS engine hacking, I
think)
- I don't understand how this differs from the previous. I presume they're the same.

 * number of objects
- the output i generate is csv, and depending on flags, you automatically get object counts (of course, it's BringYourOwnCSVParser).

afaik JSD doesn't currently retain timestamps for object creation. This could be added.

A lot of the basics are covered in the bug i'm working on.

The graph bits aren't. I think that getting the graph stuff efficiently would require a lot of work. I was planning on doing it eventually but I don't expect to do it this month.

I have yet another patch which offers a very basic api to allow people to get the gc_mark_debug output sent to a file of their choice from jsd.

If someone wanted to write a basic tool to load gc_mark_debug files (unfortunately you really don't want to try this at home. a simple 4 browser window + venkman app resulted in a 220mb file [venkman was to blame for 190mb]) and make pretty graphs from them, I could probably help by providing an api to get a JSObject by address so that someone could then start probing any individual object listed along the graph (including trying to make it unreachable, and then running the gc_mark_debug stuff again to get a new graph). Probably if someone wants to do this they should implement:
1. a gc_mark_debug graph parser.
2. a way to diff two graphs (so that you can show people what happens when a one severs a link to a node).
3. a way to present the graph as a pretty tree. (i think a simple xul tree would work since the graphs that you get from mark debug are actually trees and have no loops.)

1+3 shouldn't be too hard to implement fairly quickly if someone was in a hurry :) - although i'm not really sure that i'd want to try running js_gc again after having pulled in that world, perhaps it'd be better to ask rdf or some c++ creature to hold the data so that it doesn't appear in the next js_gc.

I'll gladly provide the glue to let people get from the pointers listed and start doing evil stuff to the objects :). one minor hazard of course is that an object represented by the graph may really have no interest in being used from the ui thread, and currently could have an expectation that it wouldn't be. I have patches which would let the poor object continue to remain unmolested (and not hurt the app ...), but they're not yet in cvs :) -- fwiw, such an object today would kill venkman if someone tried to use venkman to poke the object (actually venkman would kill itself long before it managed to grab the object, but...). 

 * principal (does this differ from parent chain?)
- I believe it's possible to grab an object which has different principals than you. I think you would just have problems trying to use its properties.

 * sum over objects of time since the object was last touched
- huh? do you want to know if an object hasn't been used in a while?
Blocks: 453420
QA Contact: jrgmorrison → xptoolkit.widgets
This could be useful to reduce memory usage of the browser.
Whiteboard: [MemShrink]
(In reply to Marco Castelluccio from comment #3)
> This could be useful to reduce memory usage of the browser.

It could, but unless someone's actively working on it the bug isn't much use.  We have per-compartment reporters in about:memory now, which are higher-level but still useful.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.