Date: Fri, 2 Dec 2005 23:49:37 -0800 From: Jason Evans <jasone@canonware.com> To: Jon Dama <jd@ugcs.caltech.edu> Cc: current@freebsd.org Subject: Re: New libc malloc patch Message-ID: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> In-Reply-To: <Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu> References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com> <Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 29, 2005, at 12:06 PM, Jon Dama wrote: > There exists a problem right now--localized to i386 and any other arch > based on 32-bit pointers: address space is simply too scarce. > > Your decision to switch to using mmap as the exclusive source of > malloc > buckets is admirable for its modernity but it simply cannot stand > unless > someone steps up to change the way mmap and brk interact within the > kernel. There's a new version of the patch available at: http://www.canonware.com/~jasone/jemalloc/jemalloc_20051202b.diff This version of the patch adds the following: * Prefer to use sbrk() rather than mmap() for the 32-bit platforms. * Lazily create arenas, so that single-threaded applications don't dedicate space to arenas they never use. * Add the '*' and '/' MALLOC_OPTIONS flags, which allow control over the number of arenas. As of this patch, all of the issues that were brought to my attention have been addressed. This is a good time for additional review and serious benchmarking. Thanks, Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B746373-8C29-4ADF-9218-311AE08F3834>