Andreas Gal :gal Reporter
	Description • 14 years ago

description lifted from stuart's email:

It should be pretty trivial.  Most of the code runs, the biggest issue is just how to hook it up to the system.  We've got different ways we use on each OS.  On Windows, we replace the CRT which works great.  On Linux, we can just build a dynamic library, link to it, and the dynamic linker takes over.  On Mac, we wrote code to hook in to the OS's zone system.  Check out: http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/jemalloc.c#6380

Basically on the Mac, there is this zone system, which is basically just a list of things that can allocate.  It has some weird characteristics though, such as free() walks through each zone and asks if the zone owns the object and if so then calls the zone's free function.  This means that there are a number of bugs in MacOS where the OS double frees things, beucase if nothing owns it, nothing frees it!  We optimized that a bit, so that we could check as well.

Because the Mac dynamic linker doesn't work the same as Linux, it is difficult to get our code to load fast enough to replace the default zone before other allocations happen.  We ended up using the linker trick here:
http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/Makefile.in#141 to get it to happen early, but it wasn't quite perfect.

If you can get the stuff above to work well, it would probably be best, but alternatively you could use #defines or see if GCC's wrap stuff works (like we're using on Android) to just overwrite allocations throughout all of Mozilla's code and let the OS/system libraries allocate things in its own space.

Anyways, I don't think any of this would be a ton of work.  Maybe a week of trying a few different things and running it through our unit tests?  We had jemalloc running on Mac, so at worst you're just looking at a little bitrot of ifdefs in the code.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 14 years ago

So is this blocking bug 414946?  Or a dup?