diff options
author | Carlos O'Donell <carlos@systemhalted.org> | 2015-10-07 22:21:36 -0400 |
---|---|---|
committer | Carlos O'Donell <carlos@systemhalted.org> | 2015-10-07 22:21:36 -0400 |
commit | e4bc326dbbf7328775fe7dd39de1178821363e0a (patch) | |
tree | 0574e1b889b71e501804b823857803348d282fc0 /CONFORMANCE | |
parent | 58a3a98d8f3488b659318b1a1c6efc169a6f06bf (diff) | |
download | glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.tar.gz glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.tar.xz glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.zip |
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
Diffstat (limited to 'CONFORMANCE')
0 files changed, 0 insertions, 0 deletions