Re: New libc malloc patch

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
>> 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

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.

David Xu