New libc malloc patch

[Maxim Sobolev]

Just curious what is the grand plan for this work? I wonder if it will 
make sense to have two malloc's in the system, so that user can select 
one which better suits his needs.

-Maxim

Jason Evans wrote:
> There is a patch that contains a new libc malloc implementation at:
> 
> http://www.canonware.com/~jasone/jemalloc/jemalloc_20051127a.diff
> 
> This implementation is very different from the current libc malloc.  
> Probably the most important difference is that this one is designed with 
> threads and SMP in mind.
> 
> The patch has been tested for stability quite a bit already, thanks 
> mainly to Kris Kennaway.  However, any help with performance testing 
> would be greatly appreciated.  Specifically, I'd like to know how well 
> this malloc holds up to threaded workloads on SMP systems.  If you have 
> an application that relies on threads, please let me know how 
> performance is affected.
> 
> Naturally, if you notice horrible performance or ridiculous resident 
> memory usage, that's a bad thing and I'd like to hear about it.
> 
> Thanks,
> Jason
> 
> === Important notes:
> 
> * You need to do a full buildworld/installworld in order for the patch 
> to work correctly, due to various integration issues with the threads 
> libraries and rtld.
> 
> * The virtual memory size of processes, as reported in the SIZE field by 
> top, will appear astronomical for almost all processes (32+ MB).  This 
> is expected; it is merely an artifact of using large mmap()ed regions 
> rather than sbrk().
> 
> * In keeping with the default option settings for CURRENT, the A and J 
> flags are enabled by default.  When conducting performance tests, 
> specify MALLOC_OPTIONS="aj" .
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 
> 
>