From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 04:56:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40F8F106564A for ; Thu, 5 Apr 2012 04:56:47 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 209588FC08 for ; Thu, 5 Apr 2012 04:56:47 +0000 (UTC) Received: from [192.168.168.4] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 534622841A for ; Wed, 4 Apr 2012 21:56:46 -0700 (PDT) From: Jason Evans Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 21:56:45 -0700 Message-Id: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> To: current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 04:56:47 -0000 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=