Date: Sun, 10 May 2020 14:09:34 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: mallocng progress and growth chart I just pushed a big queued set of changes to mallocng, including some directions that didn't go well and were mostly reversed but with improvements to the old. These include: - Fixes to definitions of some size classes where counts didn't fit in a power-of-two sized mmap or containing-group. - Fixing bad interaction between realloc and coarse size classing (always causing malloc-memcpy-free due to size class not matching; this was what was making apk and some other things painfully slow). - Coarse size classing down to class 4 (except 6->7). This tends to save memory in low-usage programs. - Improvements to logic for single-slot and low-count groups to avoid situations that waste lots of memory as well as ones that unnecessarily do eagar allocation. - Flipping definition/dependency of aligned_alloc/memalign so that legacy nonstd function is not used in definition of std functions. - New bounce counter with sequence numbers and decay, so that bounces with lots of intervening expensive (mmap/munmap) ops don't get accounted, and classes in bouncing state (retaining a free group unnecessarily to avoid cost of un- and re-mapping) can return to non-bouncing state. I've also hacked up a test program that probes and prints the growth sequence at each size just below a step in size class or page boundary. This is intended to verify that the emergent behavior from the allocation strategy rules in mallocng isn't doing anything horribly stupid. For each size, 200 mallocs are performed and if the result is the start of a new group, the size/type of the allocation is printed. The form 'NxZ' indicates a normal group of N slots each of slot size Z (Z-4 usable). The form 'Nk' indicates a single-slot group where the mapping length (N kB) is less than the nominal slot size; it shows places where the strategy chose to use individual mmap below the hard mmap threshold to save space and preserve individual freeability. (And in principle these allocations should be amenable to mremap for realloc, but it's not used yet.) Source (with nasty poking at implementation internals, so build with -no-builtin or -ffreestanding) is also attached. Rich View attachment "growth.c" of type "text/plain" (1549 bytes) View attachment "growth.txt" of type "text/plain" (13063 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.