atom feed19 messages in org.freebsd.freebsd-currentRe: contrib/jemalloc
FromSent OnAttachments
Jason EvansApr 4, 2012 9:56 pm 
John BaldwinApr 5, 2012 6:32 am 
Konstantin BelousovApr 5, 2012 10:52 am 
Jason EvansApr 5, 2012 11:55 am 
Konstantin BelousovApr 5, 2012 12:09 pm 
Jason EvansApr 5, 2012 3:47 pm 
David O'BrienApr 12, 2012 11:40 am 
Jason EvansApr 12, 2012 1:19 pm 
David O'BrienApr 13, 2012 3:42 pm 
Jason EvansApr 13, 2012 7:34 pm 
Doug BartonApr 20, 2012 10:33 am 
Pedro GiffuniApr 20, 2012 11:17 am 
Doug BartonApr 20, 2012 1:35 pm 
Pedro GiffuniApr 20, 2012 2:13 pm 
Doug BartonApr 20, 2012 2:56 pm 
David O'BrienApr 20, 2012 5:32 pm 
Pedro GiffuniApr 20, 2012 6:05 pm 
Doug BartonApr 21, 2012 12:22 am 
Pedro GiffuniApr 21, 2012 2:19 pm 
Subject:Re: contrib/jemalloc
From:John Baldwin (jh@freebsd.org)
Date:Apr 5, 2012 6:32:44 am
List:org.freebsd.freebsd-current

On Thursday, April 05, 2012 12:56:45 am Jason Evans wrote:

I have the current version of jemalloc integrated into libc as contrib/jemalloc:

http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch

This is the first update to FreeBSD's jemalloc in over two years, and the
differences are huge (faster, better introspection, hopefully fewer

bugs). This has been stable for me across numerous buildworld/installworld
iterations, as well as when running several benchmarks. There's a bugfix to openpam in the patch that des says will be obsoleted by the next
vendor import, so I'm planning to let that settle before committing. In the meanwhile, I'm hoping for some review sanity checks on the following aspects
of the patch:

* Are the symbol versioning specifications right, and are the compatibility
symbols for _malloc_options and _malloc_message workable?

* Is it acceptable to check this in directly to trunk without using a vendor
branch? For the import workflow I have planned, a vendor branch would just be extra work with no benefit that I can see.

* Is the light editing of the jemalloc manual page sufficient? Keeping the
changes minimal will make regular imports less work, but the result is less tailored to FreeBSD.

* Will the utrace feature be missed? I removed it some time ago, mainly because
traces are impossibly large for most real-world use cases.

I will only speak to this one. I do still find this useful (I used it most recently a week or so ago). It would be nice to keep if it is not a major pain to maintain.