Valgrind now supports JEMalloc builds directly

Following some sterling hackery by Alexander Potapenko and Philippe Waroquiers, Valgrind/Memcheck now has direct support for JEMalloc, tcmalloc, and any other allocation library offering a malloc-style interface.

This means you no longer need to build Firefox using –disable-jemalloc on Linux.  You do still need –enable-valgrind, to stop V freaking out when JS GC scans the stack, but that’s no big deal.

To use this, you need to give Valgrind the flag –soname-synonyms=somalloc=NONE.  This tells it that the bundle of functions it needs to intercept (malloc, etc) live in the main executable instead of in libc.

You need a Valgrind trunk build of 11 May or later (svn r12559).

On MacOSX 10.7, all of this is irrelevant, since V appears to run a normal JEMalloc’d build  just fine.

On Android, the same trickery gives support for JEMalloc, but requires some extra hacks  which are not in the repo, so you can’t use it as-is.  I also have a bunch of code which checks for cross-DSO mismatches (eg, alloc by JEMalloc, free by libc), but that is also not committed yet.

Other recent developments, that you might want to upgrade to a trunk svn build for:

  • Translation chaining — improves performance noticably in some circumstances, particularly on lower end hardware and for the lighter weight tools.
  •  AVX support — trunk now contains partial AVX instruction set support, enough to run a Firefox built with “gcc-4.7.0 -mavx -O2”. Work to give more complete support is ongoing.
  • GDB server — this has been around for a while, but doesn’t  seem widely known.  Using it, you can control Valgrind with GDB, examine data when V reports errors, single step, all the usual stuff.  To use it, start Valgrind with –vgdb-error=0 and follow the directions it prints.
  • On MacOSX, reduced noise level when running Clang/LLVM generated code.

1 response

  1. Paul Biggar wrote on :

    On OSX, it makes sense that Valgrind just works. jemalloc hooks in through the normal system allocator, so the libc routines are the ones used.

    That said, I wonder if that would cause it to miss some allocations. There are a large number of allocations that use jemalloc directly. Certainly the JS engine does, and I think any file where the mozmalloc headers are used.