> This is why our malloc has the capability of being tuned.
> The big problem is that there is limited (no) tooling that
> makes it practical for people to actually do the tuning.

Any more info on that?

> On Wed, Apr 30, 2008 at 10:35 PM, Yao Zhao <yzhao@qnx.com> wrote:
> 
> > I have ported FreeBSD's jemalloc to QNX.
> > So far on SMP it performs better than our stock malloc in libc with my
> > test case but on UP it is worse than our stock one. I still have something
> > to turn on to optimize.
> >
> > I wrote a small program testm to test malloc and free, it will create
> > threads as command line indicated if no arg then it will run with single
> > thread(main).
> >
> 
> [ Malloc numbers snipped ]
> 
> Ahh the joys of malloc optimization =;-)
> 
> This is a deep and involved topic ... and not that it isn't worth
> investigating, but it has been looked
> at lots before and the secret is really in the benchmarks and how you do the
> timing.  I'd suggest
> re-using one of the hundreds of existing benchmarks but also then comparing
> that to what real
> world applications actually do ... which is where the end solution to the
> 'build a better malloc
> problem' comes in.  Each application has its own sweet spot in the
> configuration of malloc.  This
> is why our malloc has the capability of being tuned.  The big problem is
> that there is limited (no)
> tooling that makes it practical for people to actually do the tuning.
> 
> Not to mention the fact that for a 'desktop' type environment, tuning
> applications is entirely academic
> (neat idea, but no one will do it) and for closed embedded systems, good
> developers will already have
> mitigated their memory management to tailored memory pools for frequently
> used dynamic objects.
> 
> In any case, I'm interested to see where this thread goes =;-)
> 
> Thomas
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post7539


I totally agree!
I didn't test too much and only run a program to do this

struct run{
   int size,
   int times;
} test_run[] = {
   {2,10000},
   {4,10000},
  ...
}
for() {
  for() {
     p=malloc(test_run[i].size);
     free(p);
}
}

In real world some apps like browser, database might malloc, free very frequently but rare I agree.

If you read lib/c/alloc and read jemalloc source code you will find jemalloc is really smp optimized.
for example:
if  _Multi_threaded then we are going to handle multi thread case, it didn't directly call pthread_mutex_lock and it 
called pthread_mutex_trylock, why? On SMP I won't say this 100% better but if these threads are all running on different
 cpu then we are much better than pthread_mutex_lock, right? Probably on most OS trylock is a cmpxchg or spin but 
mutex_lock is kernel call on QNX if you can't lock it, on other OS should be same thing because you have to wait 
schedule. In this case probably spin is better than kernel call.
what I want to say is just reading code you will feel difference.

static inline unsigned
malloc_spin_lock(pthread_mutex_t *lock)
{
        unsigned ret = 0;

        if (__isthreaded) {
                if (_pthread_mutex_trylock(lock) != 0) {
                        unsigned i;
                        volatile unsigned j;

                        /* Exponentially back off. */
                        for (i = 1; i <= SPIN_LIMIT_2POW; i++) {
                                for (j = 0; j < (1U << i); j++)
                                        ret++;

                                CPU_SPINWAIT;
                                if (_pthread_mutex_trylock(lock) == 0)
                                        return (ret);
                        }

                        /*
                         * Spinning failed.  Block until the lock becomes
                         * available, in order to avoid indefinite priority
                         * inversion.
                         */
        ...