This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Malloc Internals on the Wiki...
- From: Rical Jasan <ricaljasan at pacific dot net>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 9 Jul 2016 14:24:32 -0700
- Subject: Re: Malloc Internals on the Wiki...
- Authentication-results: sourceware.org; auth=none
- References: <xneg73lc7a.fsf@greed.delorie.com>
On 07/08/2016 08:31 PM, DJ Delorie wrote:
> Hopefully most of you remember that I mentioned I'd be working on
> malloc. As part of that, I've put together a "malloc internals"
> document, which I just posted on the Wiki (not linked anywhere yet,
> will probably add to 5.4):
>
> https://sourceware.org/glibc/wiki/MallocInternals
>
> Comments welcome!
>
This is great! I had just started reading malloc.c the other day, and
this is a very well written high-level overview of what was going on in
there. The diagrams are also very well made. Thank you.
Few typos:
"They're sorted later, in malloc, in order to give them once chance to
be quickly re-used." (Unsorted bin description.) -- s/once/a/ ?
"...chunks are stored stored by size." (Above Large Bin "Next Size"
Chains diagram.) -- repeated stored
"...there may be a limit to how many such mapping there can be at one
time." (Malloc Algorithm, step 1.) -- s/mapping/&s/
Questions:
In Malloc Algorithm, I know it's just an overview, but the flow seems
strange at step 7. It says, "If we still have chunks in the fastbins,
...", but step 4 said, "...take everything in the fastbins...". How
would there still be anything in the fastbins?
The rest of step 7 says, "...consolidate those and repeat the previous
two steps." Step 6 ends with, "...search the appropriate large bin, and
successively larger bins, until a large-enough chunk is found." If
there are still chunks in the fastbins, and we wind up looping through 5
and 6, are we looking for an even better candidate than before? It
seems like we wouldn't do all that over again if we had found a suitable
chunk.
Of course, maybe I should just finish reading malloc.c. :)
Great work, though. It's nice to see high-quality documentation like
this, and not a page full of stub sections marked TODO. This certainly
seems ready for 5.4.
Rical