This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[WIP] Making free coalescing on-line
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: libc-alpha at sourceware dot org
- Date: Mon, 9 Dec 2013 18:06:19 +0100
- Subject: [WIP] Making free coalescing on-line
- Authentication-results: sourceware.org; auth=none
- References: <20131208023415 dot GA5877 at domone dot podge>
Another area of improving malloc is high variance in time spent,
this happens mostly in free. There are factors that could cause that.
1) Requesting/returning memory to system, this should be discussed
separately.
2) Inter-thread interaction, Thread A allocates memory which is then
returned by thread B. This cannot be completely eliminated, best
solution that I came of is have atomic queue where other threads return
memory and creator thread consuming queue and doing actual free. This
still has some variance but is better than slowdown from other threads
taking lock to make free.
3) When factors above are handled we are left with time spend by
consolidation.
We currently use fastbin which complicate situation. There are several
ways out of it, one is to use separate heaps for fast and normal chunks
and use small normal chunks only when fast heap is full.
With bit of care we could coalesce regular bin chunks rigth away, here is
how:
We keep authoritative structure of freed chunks, we write at start and
end of each chunk a pointer to entry into that structure. When freeing
chunk we check if neighbours pointers are valid, then if authoritative
structure data represents adjacent chunk and do coalescing if so.
Comments?