Date: Wed, 4 Apr 2012 21:56:45 -0700 From: Jason Evans <jasone@canonware.com> To: current@freebsd.org Subject: contrib/jemalloc Message-ID: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com>
next in thread | raw e-mail | index | archive | help
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. Thanks, Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?431CB493-836B-4DF4-AC42-A7C6ABF7DE3E>