New libc malloc patch
davidxu at freebsd.org
Sat Dec 3 00:26:02 PST 2005
Jason Evans wrote:
> 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
> There's a new version of the patch available at:
> 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.
I have a question about mutex used in the patch, you are using
a spin loop, isn't it suboptimal ? and a thread library like libpthread
supports static priority scheduling, this mutex does not work, it
will causes a dead lock, if a lower priority thread locked the mutex,
and preempted by a higher priority thread, and the higher priority
thread also calls malloc, it will spin there to wait lower
priority thread to complete, but that will never happen.
More information about the freebsd-current