The browser uses jemalloc. The shell should as well to make performance testing in the shell more meaningful.

Has there been any progress on this bug? Having a flag to enable jemalloc sounds very appealing.

It's next on my list.

njn: I believe valgrind won't run properly with jemalloc, so what do I need to do to make this easier (or not harder) for valgrind users? - Doc fixes? - are there code changes which would simplify things? - Are there scripts that run valgrind builds that should be changed to add --disable-jemalloc?

Bug 503249 aims to add Valgrind annotations to jemalloc, but it never went anywhere because the jemalloc author never responded. So disabling jemalloc is the best bet. I think if you want to run Valgrind on the browser you now need to configure with --enable-valgrind anyway, so we might as well do the same thing with the shell. I'm not aware of any scripts that need changing. If there are, I'm sure you'll find out about them after landing a patch :)

At the moment this is a pain because the actual jemalloc build happens in the top-level tree at memory/jemalloc, and all the proper flags are passed down to js/src/configure which just uses them. I don't know that duplicating memory/jemalloc into js/src makes a lot of sense, but maybe we can figure out a smarter way to let you point --with-jemalloc at the path to a browser objdir that has libjemalloc?

This enables jemalloc in the shell. It does so by default, because that seemed like the right default. Most of the changes are because @topsrcdir@/configure.in and js/src/configure.in got out of sync. Fixing that in general is obviously a low priority. This costs us (on linux) 2% on sunspider (string-validate-input is worst with 9% slowdown) and 6% on v8 (splay is 23% slower, raytrace is 12% slower). Benchmarks on other systems welcome.

(In reply to comment #6) > This costs us (on linux) 2% on sunspider (string-validate-input is worst with > 9% slowdown) and 6% on v8 (splay is 23% slower, raytrace is 12% slower). Are the numbers for thread-safe shell build?

(In reply to comment #7) > Are the numbers for thread-safe shell build? No. Very different numbers on thread-safe build. 9% speedup on splay. 2% slowdown on raytrace. Overall 20ms/5725ms speedup on v8, which is deep in the noise. On SS, the results are identical with jemalloc and without. Oddly enough, with jemalloc enabled, the threadsafe build is faster than non-threadsafe (600ms vs 570ms). Maybe we should have that always on.

Comment on attachment 466351 [details] [diff] [review] Enable jemalloc (by default) in shell Hg symlinks don't work on filesystems that don't support symlinks, unfortunately. :-/ I'm not sure what the best course of action is here. We can copy all of memory/ into js/src/memory, but then we have to keep it in sync, etc. We might be able to convince the build to build ../../memory, but that will break with source tarball releases (and the build system might not actually like it).

What filesystems don't support symlinks? I wouldn't imagine there is a tier 1 or 2 platform which doesn't. I don't know whether windows or android do though... Suppose we were to keep it in sync, what would be the best way to put that into the build system? As a different tactic, shaver suggested copying memory/ into the objdir when building from js/src/. I briefly tried this but got lost in the build magic.

(In reply to comment #10) > What filesystems don't support symlinks? I wouldn't imagine there is a tier 1 > or 2 platform which doesn't. I don't know whether windows or android do > though... Uh, Windows. > Suppose we were to keep it in sync, what would be the best way to put that into > the build system? We do this for the config/ directory. It's not fantastic. We enforce it via a rule in "make check" that compares the two, and people forget all the time and cause orange. > As a different tactic, shaver suggested copying memory/ into the objdir when > building from js/src/. I briefly tried this but got lost in the build magic. Probably possible, has the same downside that it won't work in a JS source release.

(In reply to comment #11) > (In reply to comment #10) > > What filesystems don't support symlinks? I wouldn't imagine there is a tier 1 > > or 2 platform which doesn't. I don't know whether windows or android do > > though... > > Uh, Windows. Ah right. I hear that has a lot of users. > > Suppose we were to keep it in sync, what would be the best way to put that into > > the build system? > > We do this for the config/ directory. It's not fantastic. We enforce it via a > rule in "make check" that compares the two, and people forget all the time and > cause orange. What if it was copied during make, and never made it into the repository? > > As a different tactic, shaver suggested copying memory/ into the objdir when > > building from js/src/. I briefly tried this but got lost in the build magic. > > Probably possible, has the same downside that it won't work in a JS source > release. I presume we could add a rule to `make release` or whatever it's called? I prefer the previous solution, it seems less hideous.

I haven't done anything on this in a while, and probably won't soon. There are two options for doing this: copying the memory/ directory into js/src, and reaching out into the memory/ directory at shell build time. Both solution have been rejected in the context of nspr (see bug 625895, though the situation was slightly different in that nspr could actually be made work without this).

(In reply to comment #3) > njn: I believe valgrind won't run properly with jemalloc Actually, now I'm not sure about that. AIUI when jemalloc is enabled, malloc/calloc/realloc/free are overridden to resolve to jemalloc functions, and Valgrind intercepts those symbols, so it may work out. One way to test is to enable jemalloc in the shell and then in some function somewhere add a deliberate one-byte buffer overflow, eg: char *buf = calloc(10); char c = buf[10]; If Valgrind's doing its stuff properly, it'll complain about a buffer overflow here, because its internal allocator adds redzones to the start and end of heap blocks.

Paul -- there's a third option, which I think was floated in the embedded-nspr bug: some kind of a JS shell build that runs from the top level directory, instead of js/src. I don't imagine this would be terribly hard to sort out, aside from some potential name collisions (like configure.in). It's even suitable for use with a standalone spidermonkey tar ball of the sort of I have proposed in bug js185src.

(In reply to comment #16) > Paul -- there's a third option, which I think was floated in the embedded-nspr > bug: some kind of a JS shell build that runs from the top level directory, > instead of js/src. This sounds to me like a much more ugly proposal than either of the other two.