mozilla

Compare Revisions

Debugging Mozilla with Valgrind

Change Revisions

Revision 17929:

Revision 17929 by BenjaminSmedberg on

Revision 17930:

Revision 17930 by Julian Seward on

Title:
Debugging Mozilla with Valgrind
Debugging Mozilla with Valgrind
Slug:
Debugging_Mozilla_with_Valgrind
Debugging_Mozilla_with_Valgrind
Content:

Revision 17929
Revision 17930
tt46    <h3>
47      Tips for improving performance and accuracy of Valgrind
48    </h3>
49    <p>
50      Running Firefox on Valgrind's Memcheck tool can be a frustr
 >atingly slow experience.&nbsp; But there are things you can do to
 > improve this.&nbsp; None of the following is by itself a silver 
 >bullet, but taken together they do help considerably.
51    </p>
52    <ul>
53      <li>Use a decent machine.&nbsp; Valgrind is tremendously me
 >mory-intensive, so the single most important factor is having a l
 >arge level 2 cache.&nbsp; 2MB&nbsp;is a bare minimum, 4MB&nbsp;or
 > more is preferable. &nbsp;Most mid-to-upper range Intel Core 2s 
 >and Core iXs have 4MB&nbsp;or larger L2/L3s and work well.&nbsp; 
 >I'd guess the latest mid-to-upper-range AMDs are also good, altho
 >ugh I haven't tried them recently.
54      </li>
55      <li>Build Firefox with "-g -O".&nbsp; Don't use a plain "-g
 >" (unoptimized)&nbsp;build.&nbsp; Checking memory references take
 >s Valgrind a lot of time.&nbsp; At -O0 (no optimization), gcc doe
 >s't do much register allocation, so the generated code has many u
 >nnecessary memory references which slow Valgrind down.&nbsp; At -
 >O (that is, -O1) most of those disappear, whilst retaining pretty
 > good stack-unwind-ability, so that Valgrind can still produce sa
 >ne stack traces.&nbsp; The dangers with running optimised code on
 > Memcheck are (1) a somewhat increased risk of false positive uni
 >nitialised-value errors, and (2) incomplete or incomprehensible s
 >tack traces.&nbsp; At -O1 neither of these seem significant.&nbsp
 >; If you want to live on the bleeding edge, and you have gcc-4.4 
 >or later, try "-g -O2".&nbsp; This appears to give reasonable res
 >ults too.&nbsp; There may be future improvements to Valgrind to m
 >itigate problem (1) at -O2, and newer gccs appear to give better 
 >debug info at high optimisation levels, thereby mitigating (2).
56      </li>
57      <li>Use 64-bit builds of Fx in preference to 32-bit builds.
 >&nbsp; 64-bit code has more available registers and better callin
 >g conventions, both of which reduce the number of memory referenc
 >es Valgrind has to check.
58      </li>
59      <li>Avoid --smc-check=all unless you really need it (becaus
 >e the JIT or JITted code crashes).&nbsp; You can avoid it if you 
 >build Fx with --enable-valgrind.&nbsp; In an ideal world we could
 > fold the relevant pieces of magic enabled by --enable-valgrind i
 >nto the Fx code base, so --smc-check would never be needed.
60      </li>
61      <li>Don't use --track-origins=yes unless you are hunting do
 >wn a specific uninitialised-value error.&nbsp; It pretty much hal
 >ves the speed of Valgrind.&nbsp; That said, it is still way faste
 >r than tracking down sources of uninitialised data by hand, and s
 >o constitutes a net programmer productivity win.
62      </li>
63      <li>Use Linux rather than MacOS.&nbsp; Unfortunately, Valgr
 >ind has difficulties in with threaded code on MacOS, which cause 
 >it to run far slower than on Linux.&nbsp; Fixing this in Valgrind
 > will not be simple.&nbsp; Such difficulties do not occur on Linu
 >x.&nbsp; If your code is single threaded you can of course ignore
 > this point.&nbsp; One crucial note, if you work on Linux, is tha
 >t you must disable JEMalloc ("ac_add_options --disable-jemalloc")
 > to get sane results from Memcheck.
64      </li>
65      <li>Use the <a class=" external" href="http://www.valgrind.
 >org/downloads/repository.html" title="http://www.valgrind.org/dow
 >nloads/repository.html">latest Valgrind trunk</a> from SVN.&nbsp;
 > It's easy to download and build.&nbsp; The trunk sometimes conta
 >ins optimizations not yet present in formal releases.&nbsp; Curre
 >nt trunk contains improvements in instrumentation of 64-bit code 
 >relative to the released 3.5.0.&nbsp; It also contains an experim
 >ental flag --vex-guest-chase-cond=yes which improves performance 
 >of the instrumented code at the cost of making the instrumentatio
 >n take a little longer, hence is useful for longer-running progra
 >ms, eg, longer runs of Fx.
66      </li>
67    </ul>
68    <p>
69      Using all these together, on a Core i5 670 (3.46 GHz) runni
 >ng 64-bit Linux, I can surf the web, reading news sites over my m
 >orning coffee, whilst running on Memcheck.&nbsp; It's obviously n
 >ot running natively, but the delays are small enough that I spend
 > most of my time reading and not much time waiting for Fx.&nbsp; 
 >Here's a recommended mozconfig:
70    </p>
71    <p>
72      <code>. $topsrcdir/browser/config/mozconfig<br>
73      mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt<br>
74      ac_add_options --enable-tests<br>
75      ac_add_options --enable-optimize="-g -O -freorder-blocks"<b
 >r>
76      ac_add_options --disable-jemalloc<br>
77      mk_add_options MOZ_MAKE_FLAGS="-j4"</code><br>
78    </p>
79    <p>
80      As per comments above, I've been experimenting recently wit
 >h -O2 rather than "-O -freorder-blocks", for maximum effect.
81    </p>

Back to History