currently we are not using jemalloc in fennec. we should fix this.
bsmedberg, ted: since we're using xulrunner-stub as our application piece, we need it to link against jemalloc. I'm not sure how to do this short of making it always link against jemalloc (perhaps that is OK). Thoughts?
as discussed on IRC, the "safe" way to do this is probably to statically link xulrunner-stub against jemalloc (dynamic linking won't work well because you don't actually know where libjemalloc.so lives until the "find libxul" code runs.
Created attachment 335101 [details] [diff] [review] ubuntu's patch to link jemalloc in to xulrunner-stub
Comment on attachment 335102 [details] [diff] [review] ubuntu patch to make jemalloc build statically i'm unsure if this patch is right for linux... do we always want this to be static? i'm not sure what all our different shared/static/libxul/notlibxul/embedding/etc cases are..
Comment on attachment 335101 [details] [diff] [review] ubuntu's patch to link jemalloc in to xulrunner-stub you want $(call EXPAND_LIBNAME_PATH,jemalloc,$(DEPTH)/memory/jemalloc)
Created attachment 335583 [details] [diff] [review] updated patch to link jemalloc to xulrunner-stub
If I use firefox-bin not xulrunner to start Firefox on Linux, where does jemalloc live in?
I just did a release build on Linux, I didn't find malloc() implementation in dist/bin binaries.
As I understand it, jemalloc should still be getting linked in via browser/app/Makefile.in for firefox... bsmedberg, is that right?
I think so, and therefore part of firefox-bin itself.
Interesting. nsBrowserApp.cpp doesn't explicit use malloc() function, so linking libjemalloc.a into firefox-bin doesn't have any effect.
We can use MKSHLIB_FORCE_ALL if we want.