Closed Bug 72748 Opened 25 years ago Closed 17 years ago

instrument JS

Categories

(Core :: JavaScript Engine, defect, P1)

x86
Windows 98
defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: cathleennscp, Unassigned)

References

Details

Attachments

(8 files)

brendan, we need help taking a closer look at JS to see if we can reduce it's 25% of memory usage allocated by the app.
Blocks: 71814
Blocks: 71874
No longer blocks: 71814
Patch coming, more to do after that. I still think my energy is better spent fixing some of my 0.9 footprint bugs, but the next patch should help others to start finding possibly bogus JS object bloat in the chrome. /be
Status: NEW → ASSIGNED
Keywords: mozilla0.9
Priority: -- → P1
Target Milestone: --- → mozilla0.9
sfraser is original contributor of dump_xpc.{cpp,h} -- I'll make sure those files get a compatible license comment with credits. /be
I've got some hacked perl scripts to pull this apart by object type and then individual object, but I'm not exactly sure what people are looking for. If we put the addresses of the objects in the ref path in, and stop truncating it, I could try to build a set of object graphs and visualize them with webdot or something. As it stands now, I can give summary stats from brendan's latest dump: strings: 7121 doubles: 238 objects: 11190 (!) Object breakdown by class: Function 9483 XULElement 504 Object 169 Error 130 Script 96 RegExp 57 NodeList 27 Text 23 Array 23 Node 22 KeyEvent 22 Document 22 With 21 XPCOutArg 20 UIEvent 20 NamedNodeMap 20 JSOptions 20 InstallVersion 20 InstallTrigger 20 HTMLOptionElement 20 HTMLImageElement 20 HTMLElement 20 Event 20 Element 20 CharacterData 20 Attr 20 15nsXPCComponents 20 Number 18 String 17 Math 16 Date 15 Call 14 Boolean 14 Arguments 14 7nsJSIID 9 WindowCollection 8 HTMLDocument 7 Window 6 HTMLInputElement 5 14nsStringBundle 5 XULDocument 4 XULCommandDispatcher 4 Navigator 4 HTMLHtmlElement 4 HTMLBodyElement 4 6nsPref 4 21nsSecureBrowserUIImpl 4 13nsRDFResource 4 13nsCharsetMenu 4 Location 3 HTMLFormElement 3 14RDFServiceImpl 3 XULTreeElement 2 XStringBundle 2 Q212nsJVMManager8Internal 2 HTMLTextAreaElement 2 HTMLTableSectionElement 2 HTMLTableRowElement 2 HTMLTableElement 2 HTMLTableCellElement 2 HTMLDivElement 2 29nsMsgAccountManagerDataSource 2 23CompositeDataSourceImpl 2 21nsMsgFolderDataSource 2 21nsAutoCompleteResults 2 20RDFXMLDataSourceImpl 2 19nsMsgStatusFeedback 2 19nsMsgComposeService 2 17nsBrowserInstance 2 16nsXULControllers 2 15nsUrlbarHistory 2 15nsCommonDialogs 2 14LocalStoreImpl 2 13nsDragService 2 12nsJVMManager 2 11nsMsgWindow 2 11nsMessenger 2 Q28nsStdURL8Internal 1PrefConfig 1 nsXULPrototypeScript_compilation_scope 1 HTMLPreElement 1 HTMLParagraphElement 1 HTMLAnchorElement 1 global 1 chrome:__messenger_content_mailWidgets.xml_mail-emailaddress 1 chrome:__global_content_xulBindings.xml_textfield 1 chrome:__global_content_xulBindings.xml_statusbar-panel 1 chrome:__global_content_xulBindings.xml_progressmeter 1 chrome:__global_content_xulBindings.xml_popups 1 chrome:__global_content_xulBindings.xml_menuitem-iconic 1 chrome:__global_content_xulBindings.xml_menuitem 1 chrome:__global_content_xulBindings.xml_menu-iconic 1 chrome:__global_content_xulBindings.xml_menu 1 chrome:__global_content_xulBindings.xml_iframe 1 chrome:__global_content_xulBindings.xml_browser 1 chrome:__global_content_xulBindings.xml_basetext 1 chrome:__global_content_treeBindings.xml_treeitem 1 chrome:__global_content_treeBindings.xml_tree 1 chrome:__global_content_toolbarBindings.xml_toolbox 1 chrome:__global_content_toolbarBindings.xml_toolbargrippy 1 chrome:__global_content_toolbarBindings.xml_toolbar 1 chrome:__global_content_toolbarBindings.xml_menubar 1 chrome:__global_content_outlinerBindings.xml_outliner 1 chrome:__global_content_outlinerBindings.xml_columnpicker 1 chrome:__global_content_menulistBindings.xml_menubutton-dual-ex 1 chrome:__global_content_autocomplete.xml_autocomplete 1 21RDFContainerUtilsImpl 1 21nsStringBundleService 1 20nsAbAddressCollecter 1 19nsOutlinerBoxObject 1 19nsMsgThreadedDBView 1 19nsMsgAccountManager 1 18nsEditorController 1 18nsBrowserBoxObject 1 17nsMsgHeaderParser 1 16nsMsgMailSession 1 15nsLocaleService 1 15nsFileTransport 1 13nsFileChannel 1 Obviously, more investigation of the Function stuff is required -- how do we want to break them down? We could get dump_xpc to tell us source file and function name, I guess. (I assume we're running GC before dumping the heap.)
Shaver: that dump comes from the GC's mark phase, show it lists only live objects. Lotta functions. More in 0.9.1, good results so far, but it's not clear what to do other than lazy load their precompiled XDR, but that's not gonna make 0.9 either. /be
Keywords: mozilla0.9mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Nothing happened in 0.9.1 yet due to this data, and there's only one day left. /be
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
FastLoad work should try to deserialize the infrequently-used function objects on demand, but not for 0.9.3. /be
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Oink. /be
Target Milestone: mozilla0.9.4 → mozilla0.9.5
This bug is too vague (JS has instrumentation, are we using it? Maybe we just need shaver's perl-fu). I'm likely to close it soon, but I'll keep it into 0.9.6 while bug 62164 gets fixed. /be
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Bumping. /be
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Hey dbaron, could you r= the forthcoming reduced patch? I'd like to get it in for 0.9.7. /be
Ugh, dbaron pointed out that I should impute GC_MARK_DEBUG from NS_TRACE_MALLOC also in js/src/xpconnect/src/Makefile.in, because nsXPConnect.cpp has two #ifdef GC_MARK_DEBUG sections. That suggests that I should move the guts of dump_xpc.cpp into an existing xpconnect/src/*cpp file and put the extern "C" prototype in some new or existing .h file. Jband, can you advise? /be
Well, I suck for not landing an updated version of the patch, but now at least I can get the dump_xpc.* stuff properly integrated into xpconnect. /be
Target Milestone: mozilla0.9.7 → mozilla0.9.8
xpcdebug.cpp would be the place for the code. xpconnect has no non-generated public headers. So, a C++ section of nsIXPConnect.idl seems like the place for anything that needs to be #includ'd by (say) the DOM. The xpconnect makefiles do not currently have an automated way to turn GC_MARK_DEBUG on and off. I've done that by hand in the past. A may to say that more globally at build time from an env var would be handy.
FWIW, I'm not real excited about the RTTI aspect of this. It *does* give nice concise (and more or less precise) info on the class of the actual wrapped object. But, it requires 'funky' builds. XPCWrappedNative::ToString (or some new subset) get's you most of the way to knowing about the class of the wrapped object without RTTI. It will only be substandard on objects that we either have not QI'd to a specific enough interface or when a fairly generic interface (that is implemented by numerous concrete classes) is used.
Maybe you should use the nsGetTypeName in xpcom/base/nsTypeInfo.cpp?
is dumpxpc.h really Copyright (C) 2000 Netscape Communications Corporation. the patch i was looking at had no - lines, and work for this bug is all in the year 2001. i'm sure i'm asleep, http://lxr.mozilla.org/mozilla/search?string=GetXPCObjectClassName has 1 hit (caller inside ifdef) and google has no hits.
> FWIW, I'm not real excited about the RTTI aspect of this So can we #ifdef it depending on whether the current platform is building with RTTI on?
Shaver, you want this bug? I foresee merge woes, but we should figure out the right way to get the dump_xpc stuff in. /be
Keywords: mozilla0.9.7mozilla1.0
Target Milestone: mozilla0.9.8 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.9
I don't have time for more here, and don't feel a strong need to get this in. I expect shaver may do some GC work on a branch soon, to be landed in 1.1, that will standardize and cleanly integrate the patch here. Moving out. /be
Keywords: mozilla1.0mozilla1.1
Target Milestone: mozilla0.9.9 → mozilla1.1
Moving out. /be
Keywords: mozilla1.1mozilla1.2
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Moving out, some of these may move to 1.3alpha shortly. /be
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Fixing TM. /be
Target Milestone: mozilla1.2beta → mozilla1.3beta
Target Milestone: mozilla1.3beta → Future
Keywords: mozilla1.2
Disowning. /be
Assignee: brendan → general
Status: ASSIGNED → NEW
-> default qa
QA Contact: pschwartau → general
We have lots of instrumentation now, from newer bugs added in the Firefox 3 era used to add the cycle collector.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: