Re: New libc malloc patch

From: David Xu <davidxu_at_freebsd.org>
Date: Sat, 03 Dec 2005 16:26:02 +0800
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
Received on Sat Dec 03 2005 - 07:26:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC