mozglue currently uses the system allocator on Android. It would be better for it to use jemalloc, especially to make things easier for bug 828845.

Comment on attachment 724082 [details] [diff] [review] Use jemalloc inside mozglue I need to find something better than using the system allocator for the pthread_atfork deadlock, because b2g will have the same problem when bug 850576 is fixed, and using the system allocator won't work there.

Comment on attachment 724393 [details] [diff] [review] Use jemalloc inside mozglue Review of attachment 724393 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the delayed review, I had to learn a bunch of stuff before I could review this :) It looks ok to me but I'm not really confident in my review, if you want more meaningful feedback you might want to get somebody else to review it as well.

Comment on attachment 724393 [details] [diff] [review] Use jemalloc inside mozglue Oh, interesting deadlock. Well, the implementation looks fine for what it's doing, and I can't think of anything better to do here.. glibc looks like it statically allocates 48 entries and then switches to calloc when out of entries, which is just a more complicated version of this.

Backed out because of M8 orange. https://hg.mozilla.org/integration/mozilla-inbound/rev/62a151ec5bdb

glandium, mwu, could this bug explain the android failures we are seeing in bug 761987?

(In reply to Doug Turner (:dougt) from comment #8) > glandium, mwu, > could this bug explain the android failures we are seeing in bug 761987? It doesn't look like this fix had any effect on the rate of occurrence of the crash: http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=761987&startday=2013-03-18&endday=2013-05-02&tree=trunk Note that the trend down to zero is believed to be that the bug was masquerading as other Android intermittent issues, not that it had been fixed.