[PATCH] libdw: add thread-safety to dwarf_getabbrev()
Sun Oct 27 18:44:00 GMT 2019
* Jonathon Anderson:
> On Sun, Oct 27, 2019 at 09:59, Florian Weimer <email@example.com> 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 <firstname.lastname@example.org <mailto:email@example.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
It increases fragmentation. Vmware's Photon distribution disables it.
> 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.
No, there is a prefill step if the cache is empty, where the cache is
populated with one arena allocation which is then split up.
> According to the comments, there might also be a 16 byte overhead per
> allocation, which would explode the small allocations considerably.
Available allocatable sizes in bytes are congruent 8 modulo (16), and
the smallest allocatable size is 24. In general, the overhead is
8 bytes. (All numbers are for 64-bit architectures.)
More information about the Elfutils-devel