[Bug malloc/30579] trim_threshold in realloc lead to high memory usage

["nicolas at freedelity dot be" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30579

--- Comment #2 from Nicolas Dusart <nicolas at freedelity dot be> ---
I apologize for any previous misunderstanding regarding the use of
trim_threshold in relation to heap fragmentation. I incorrectly assumed that it
was primarily relevant to the mmap use case, based on the message of the
commit.

I still have concerns about the recent change to the realloc function and I
would argue that it doesn't significantly mitigate fragmentation.

There are two primary reasons for my concern:

- Memory "freed" by realloc is not immediately accessible, even to the process
itself.
- The memory that is reallocated isn't necessarily positioned at the top of the
heap.

Consequently, we tend to accumulate more and more memory blocks that become
stagnant (in use cases where we initially allocate more memory than needed and
then realloc to the precise size). These blocks can't even be released back to
the system if their combined size exceeds the trim_threshold, since they don't
constitute a contiguous space at the top of the heap.

I maintain that the use of trim_threshold in this context is not ideal. We
might still want to retain the default threshold of 128K to prevent fragmenting
memory returned to the system, while also preventing the accumulation of
stagnant blocks up to 128K in our memory space.

-- 
You are receiving this mail because:
You are on the CC list for the bug.