[Bug malloc/30625] Moving "free(buf)" slows down code x1.6

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
The bad placement results in many brk calls (about three per loop iteration).
It's still present in the current sources.

The trimming heuristics are not unreasonable in this case, given how large the
BUF_SIZE allocation is. What you call “good placement” prevents heap trimming;
others have complained that we don't release memory in the middle of the heap
to the operating system, and they would call this “bad placement”.

We just don't know if the program will go to sleep after the free call, or
enter some longer computation not calling malloc/free, so if free detects that
there is a certain amount of memory that could be returned to the kernel, it
does that.

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