[Bro-Dev] bro's dlmalloc
Gilbert Clark
gc355804 at ohio.edu
Thu Aug 11 23:56:04 PDT 2011
So I was testing the threaded code on FreeBSD, and discovered I'd
forgotten to check to see if the malloc.c that shipped with bro was
thread-safe. Oops.
When I went to browse malloc.c's source, I found out that it was
dlmalloc. Further, it appears that dlmalloc is not really meant to
support threads [1]. With that in mind, I'm wondering if malloc.c is
really necessary; most systems these days have a pretty good default
allocator ([2], [3]). From what I've read, jemalloc in particular
(default allocator in FreeBSD 7+) is competitive with the Linux default
allocator (ptmalloc2 derivative) [4], and is used in one context or
another by Firefox and Facebook to help with memory fragmentation issues
[5].
For folks worried about performance, there's always tcmalloc [6]; this
comes with google perftools, but would it be a good idea to just embed
this in the project?
With the above in mind, what would y'all think about either:
*) Removing malloc.c entirely
*) Replacing dlmalloc with e.g. ptmalloc3 (which I believe to be
licensed under something BSD-like, but need to check on that) or
jemalloc (BSD-ish license [7])
--Gilbert
[1] From dlmalloc's source: "... When USE_LOCKS is defined, each public
call to malloc, free, etc is surrounded with either a pthread mutex or a
win32 spinlock (depending on WIN32). This is not especially fast, and
can be a major bottleneck..."
[2]
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/BSDcan2006_slides.pdf
[3] http://people.freebsd.org/~kris/scaling/ebizzy.html
[4] http://www.sintel.org/development/memory-jemalloc/
[5] http://www.canonware.com/jemalloc/
[6] http://googlecode.blogspot.com/2006/12/tcmalloc-success.html
[7] http://www.canonware.com/jemalloc/license.html
More information about the bro-dev
mailing list