Using SlowCalls: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 3: Line 3:
First, you need to get a tree containing Javascript instrumentation that is fully working. ({{bug|507012}} added the instrumentation, but it keeps getting perturbed by JS engine changes, so that it ends up getting mismatched JS function enters/exits.)
First, you need to get a tree containing Javascript instrumentation that is fully working. ({{bug|507012}} added the instrumentation, but it keeps getting perturbed by JS engine changes, so that it ends up getting mismatched JS function enters/exits.)


=== Option 1: mozilla-central ===
I've updated the patches in {{bug|605330}} to work on top of dvander's recent refactoring of the tracemonkey branch ({{bug|603044}}). So to get it working, you'll need to apply two sets of patches:


The current (2010-Oct-11) m-c tree's JS interpreter is in an intermediate state that I can't get the instrumentation working for. So my current workaround is to do a wholesale update to a fairly recent tracemonkey and then add some patches that fix the instrumentation there.
* First, checkout the tracemonkey branch.
 
* Apply everything in {{bug|605330}}
I boiled it down into 3 ugly patches:
* Add in an instrumentation client that just logs everything to a file ({{bug|580055}}, which needs to be updated at the time of this writing)
 
* switch to tracemonkey
  hg qimport 'http://people.mozilla.org/~sfink/slowcalls-proto/import-tracemonkey'
* apply instrumentation fixes + a bunch of other irrelevant crud that I had lying around
  hg qimport 'http://people.mozilla.org/~sfink/slowcalls-proto/profiling-megapatch'
* add an instrumentation client that just logs everything to a file
  hg qimport 'http://people.mozilla.org/~sfink/slowcalls-proto/slowcalls-logger'
 
That first patch is likely to rot rather quickly. If so, you could clone revision 19b462ec16a0 and copy out the js/src subtree from there instead.
 
=== Option 2: tracemonkey ===
 
The patches in {{bug|602067}} will get to the same state as the patched mozilla-central tree, above, but dvander has rewritten the JS engine integration in {{bug|603044}} to be much, much nicer. None of my patches will be needed after this lands. But I haven't tried it yet.


== Building with instrumentation ==
== Building with instrumentation ==

Revision as of 07:30, 22 October 2010

Getting a tree with instrumentation

First, you need to get a tree containing Javascript instrumentation that is fully working. (bug 507012 added the instrumentation, but it keeps getting perturbed by JS engine changes, so that it ends up getting mismatched JS function enters/exits.)

I've updated the patches in bug 605330 to work on top of dvander's recent refactoring of the tracemonkey branch (bug 603044). So to get it working, you'll need to apply two sets of patches:

  • First, checkout the tracemonkey branch.
  • Apply everything in bug 605330
  • Add in an instrumentation client that just logs everything to a file (bug 580055, which needs to be updated at the time of this writing)

Building with instrumentation

You will need to configure with both --enable-functiontimer and --enable-trace-jscalls:

 ac_add_options --enable-trace-jscalls
 ac_add_options --enable-functiontimer

I've also been running with --enable-debug, which probably provides a lot more verbosity in the functiontimer logs. But I haven't tried without it, so I'm not sure.

 ac_add_options --enable-debug

Configure your profile

With the patched mozilla-central variant, the instrumentation will not work with Jaegermonkey, so you'll need to go to about:config and turn off JM:

 javascript.options.methodjit.chrome = false
 javascript.options.methodjit.content = false

If you are using a version that has bug 603044 patch within it, then this will not be an issue (his patch fixes the instrumentation for JM as well.)

Run your scenario

Set the following environment variables before running your scenario:

 NSPR_LOG_MODULES=JSDiagnostics:5
 NSPR_LOG_FILE=/tmp/minefield.log
 MOZ_FT=/tmp/minefield.tl

For example, I run with this command:

 NSPR_LOG_MODULES=JSDiagnostics:5 NSPR_LOG_FILE=/tmp/minefield.log MOZ_FT=/tmp/minefield.tl dist/bin/firefox -no-remote -P Blank

Exit the browser when done.

Produce the jscalls output

Run the 'process-jscall-logs' script from bug 558200 giving the two log files generated above as options, and the '-f slowcalls' flag:

 process-jscall-logs -f slowcalls /tmp/minefield.log /tmp/minefield.tl

(though if you're using the default names, you don't actually have to give them on the command line.) This will produce a file /tmp/slowcalls.html. Go to file:///tmp/slowcalls.html in a browser to view the output.