627206 - jemalloc heap profiling

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Paul Biggar]

Attachment: Add tip jemalloc

Recent versions of jemalloc support heap profiling, which should be useful to njn during his crusade on memory usage. (We can't simply upgrade the tree to the latest version, since that relies on getting lots of build configury right, this is the simplest thing that will work on Linux only).

Before compiling, run jemalloc_autoconf.sh from js/src, which handles the autoconf changes needed to link in jemalloc.

To get a profile, run like so:

  MALLOC_CONF=prof:true objdir/js perfect.js

This creates a .heap file in your cwd.
 Analyze the heap using jemalloc/bin/pprof. --help will show you how.

Other MALLOC_CONF options are available: http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html#opt.prof


This doesn't work on Mac (ironic, right) or windows.

Comment 1

[Nicholas Nethercote [inactive]]

Did you forgot to add jemalloc_autoconf.sh to the patch?

Comment 2

[Paul Biggar]

(In reply to comment #1)
> Did you forgot to add jemalloc_autoconf.sh to the patch?

I did, but actually it's not necessary; I included the generated files in the patch. Just run autoconf213 in js/src as normal.

Comment 3

[Nicholas Nethercote [inactive]]

For my own assistance, here are the instructions pbiggar and I hammered out on IRC for my Ubuntu 10.04 machine:

- apply patch
- in js/src/:

    cd jemalloc
    autoconf2.50
    touch config.stamp.in
    cd ..
    autoconf2.13
    mkdir debug64
    cd debug64
    ../configure --enable-debug --disable-optimize --enable-valgrind
    make --quiet -j 2

The output of pprof is surprising, though:

[ocean:~/moz/ws3/js/src] perl jemalloc/bin/pprof --text debug64/js jeprof.4557.
0.f.heap
Using local file debug64/js.
Using local file jeprof.4557.0.f.heap.
Total: 0.0 MB
     0.0  61.1%  61.1%      0.0  61.1% _nl_make_l10nflist
     0.0  18.3%  79.4%      0.0  18.3% _nl_intern_locale_data
     0.0   9.9%  89.4%      0.0   9.9% read_alias_file
     0.0   8.7%  98.1%      0.0   8.7% extend_alias_table
     0.0   0.9%  99.0%      0.0   0.9% *__GI___strdup
     0.0   0.9%  99.9%      0.0   0.9% *__GI___strndup
     0.0   0.1% 100.0%      0.0   0.1% new_composite_name
     0.0   0.0% 100.0%      0.0 100.0% *__GI_setlocale
     0.0   0.0% 100.0%      0.0 100.0% __libc_start_main
     0.0   0.0% 100.0%      0.0  18.6% _nl_expand_alias
     0.0   0.0% 100.0%      0.0  99.0% _nl_find_locale
     0.0   0.0% 100.0%      0.0  18.3% _nl_load_locale
     0.0   0.0% 100.0%      0.0 100.0% _start
     0.0   0.0% 100.0%      0.0 100.0% main

That's it.  Looks like it's not hooking into the JS shell properly somehow.  pbiggar is looking into it.

Comment 4

[Jason Evans]

The patch is pretty big and I may have missed something, but it looks like you might be building in both the memory/jemalloc version of jemalloc and the version included in the patch.

Comment 5

[Paul Biggar]

(In reply to comment #4)
> The patch is pretty big and I may have missed something, but it looks like you
> might be building in both the memory/jemalloc version of jemalloc and the
> version included in the patch.

The js shell doesn't build with mozalloc/jemalloc (see bug 580409), so there can't be a conflict.

(The patch is mostly the jemalloc directory, which is just a direct import from the canonware repo).

Comment 6

[Paul Biggar]

I wrote a simple test case and linked in jemalloc, and got nothing. I tried using tcmalloc instead, and got proper results in the heap profiles. So either I'm doing the jemalloc part wrong, or there's a bug in jemalloc. Working on it.

Comment 7

[Paul Biggar]

Attachment: Change profiling library

jasone suggested there were problems on 32 bit linux, but that --disable-prof-libgcc might work. It does give profiling info for a small test program, but when I run spidermonkey I don't get any useful profiling data.

I suggest that anyone wanting to use this should try on a different platform, probably 64-bit.


I've included jasone's response below for posterity:

> I reproduced your results on a 32-bit Ubuntu system this morning.  In looking
> back through my development notes, I found this from October 2, 2010:
> 
> ---
> On my 32-bit Ubuntu 10.04 system, I have to specify --disable-prof-libgcc.
> This is perplexing, because it works on a similar VMWare guest on my work
> laptop.  I see that google-perftools only uses libgcc for x64, but I suspect
> that's just because they already had a hand-coded backtrace implementation for
> 32-bit systems.
> ---
> 
> My guess is that when I wrote that, I was mistaken about the jemalloc
> configuration for the VMWare guest, and that it was actually using libunwind.
> I just verified that backtracing works with --disable-prof-libgcc, and with
> --enable-prof-libunwind (assuming libunwind is found by the configure script).
> 
> I added some debug spew for the libgcc-based backtracing code in jemalloc, and
> it looks to me like libgcc is simply failing.  Visual inspection of the related
> code in gcc convinces me that jemalloc is using the API correctly.  The next
> debugging step would be to use a libgcc with debug symbols/source and trace 
> through backtracing with gdb.