[Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead

["kkylheku at gmail dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From kkylheku at gmail dot com  2008-07-18 20:07 -------
(In reply to comment #2)
> I think it would not fix the following (IMHO in practice more likely) 
situation:
> 1. lot's of malloc/free from the main arena
> 2. a single sbrk(+something) call from the app

IMHO, apps that call sbrk deserve less than optimal behavior from malloc, such 
as memory not being returned when it is freed.

> 3. lot's of free() from the main arena
> -- now every free() can still incur an
> sbrk(0) call because the end of the main arena never can pass the user-
allocated
> space
> I think the proper fix would be to prevent or alleviate the sbrk(0) in every
> free(), given that sbrk(0) is very expensive (but see below).

But, seeing below, it is successfully argued that sbrk(0) is actually not 
expensive at all thanks to cashing. The remaining problem is that the freed 
memory won't be returned to the operating system.  But the application 
arguably deserves that, because it interfered with malloc by calling sbrk
(+delta).


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1128

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.