[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