[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200510180934.GV21576@brightrain.aerifal.cx>
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.
