]> git.ipfire.org Git - thirdparty/glibc.git/commit
malloc: Consistently apply trim_threshold to all heaps (Bug 17195)
authorCarlos O'Donell <carlos@systemhalted.org>
Thu, 8 Oct 2015 02:21:36 +0000 (22:21 -0400)
committerCarlos O'Donell <carlos@systemhalted.org>
Thu, 8 Oct 2015 02:21:36 +0000 (22:21 -0400)
commite4bc326dbbf7328775fe7dd39de1178821363e0a
tree0574e1b889b71e501804b823857803348d282fc0
parent58a3a98d8f3488b659318b1a1c6efc169a6f06bf
malloc: Consistently apply trim_threshold to all heaps (Bug 17195)

In the per-thread arenas we apply trim_threshold-based checks
to the extra space between the pad and the top_area. This isn't
quite accurate and instead we should be harmonizing with the way
in which trim_treshold is applied everywhere else like sysrtim
and _int_free. The trimming check should be based on the size of
the top chunk and only the size of the top chunk. The following
patch harmonizes the trimming and make it consistent for the main
arena and thread arenas.

In the old code a large padding request might have meant that
trimming was not triggered. Now trimming is considered first based
on the chunk, then the pad is subtracted, and the remainder trimmed.
This is how all the other trimmings operate. I didn't measure the
performance difference of this change because it corrects what I
consider to be a behavioural anomaly. We'll need some profile driven
optimization to make this code better, and even there Ondrej and
others have better ideas on how to speedup malloc.

Tested on x86_64 with no regressions. Already reviewed by Siddhesh
Poyarekar and Mel Gorman here and discussed here:
https://sourceware.org/ml/libc-alpha/2015-05/msg00002.html
ChangeLog
malloc/arena.c