This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Malloc Internals on the Wiki...


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]