Re: [PATCH] libdw: add thread-safety to dwarf_getabbrev()

[Jonathon Anderson <jma14 at rice dot edu>]

On Sun, Oct 27, 2019 at 09:59, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Mark Wielaard:
>
> > >  Current glibc versions have a thread-local fast path, which should
> > >  address some of these concerns.  It's still not a bump-pointer
> > >  allocator, but at least there are no atomics on that path.
> >
> >  Since which version of glibc is there a thread-local fast path?
>
> It was added in:
>
> commit d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc
> Author: DJ Delorie <dj@delorie.com <mailto:dj@delorie.com>>
> Date:   Thu Jul 6 13:37:30 2017 -0400
>
>     Add per-thread cache to malloc
>
> So glibc 2.26.  But it is a build-time option, enabled by default, but
> it can be switched off by distributions.

I doubt any non-mobile distros would disable it, the cost seems fairly 
small.

My main concern is that it seems like chunks will only enter the 
thread-local cache in the presence of free()s (since they have to enter 
the "smallbins" or "fastbins" first, and those two at a glance seem to 
be filled very lazily or on free()); since the free()s are all on 
dwarf_end this would pose an issue. I could also be entirely mistaken, 
glibc is by no means a simple piece of code.

According to the comments, there might also be a 16 byte overhead per 
allocation, which would explode the small allocations considerably.

-Jonathon