Closed Bug 323075 Opened 15 years ago Closed 9 years ago
Script memory use monitoring extension
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?
This could be useful to reduce memory usage of the browser.
(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: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.