Question about the spare chunk

cee1 fykcee1 at
Thu Dec 4 21:17:52 PST 2014


Thanks for the reply!

2014-12-04 7:41 GMT+08:00 Jason Evans <jasone at>:
> On Dec 3, 2014, at 6:17 AM, cee1 <fykcee1 at> wrote:
>> Here the old spare chunk is replaced by the new one and dealloced.
>> The deallocating process is done without the lock protection. In this
>> lockless period, is it possible another arena_chunk_dealloc running in
>> another thread replaces and deallocates ** our new spare chunk ** ?
>> Which is still in the chunks_dirty tree and will be accessed by the
>> purge process later.
> The chunk being passed to chunk_dealloc() has been completely dissociated from the arena prior to the malloc_mutex_unlock() call, so there's no way for it to be accessed by the arena again.  If another thread concurrently calls into arena_chunk_dealloc() to deallocate the current spare, then the same logic holds for that chunk deallocation.

Could you describe this more detail?

"""   <--- code snippet in arena_chunk_dealloc()

assert(arena_mapbits_dirty_get(chunk, map_bias) ==
arena_mapbits_dirty_get(chunk, chunk_npages-1));
 * Remove run from the runs_avail tree, so that the arena does not use
 * it.
arena_avail_remove(arena, chunk, map_bias, chunk_npages-map_bias, false, false);

if (arena->spare != NULL) {
    arena_chunk_t *spare = arena->spare;
    arena->spare = chunk;


What I understand:
1. The chunk may be whole dirty, i.e. n_dirty == 1.

2. After calling arena_avail_remove, the chunk may still be in

3. After calling unlock(and before locking again), some other
arena_chunk_dealloc may dealloc previous arena->spare, which is still
in chunks_dirty.

Am I right?

BTW, in function arena_run_regind(), I notice a "plus 1" in
define SIZE_INV(s)     (((1U << SIZE_INV_SHIFT) / (s)) + 1)

Why we need this?


- cee1

More information about the jemalloc-discuss mailing list