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

[bugzilla1 at malloc dot de]

------- Additional Comments From bugzilla1 at malloc dot de  2008-03-28 17:44 -------
That would fix the test case in question, but only because it prohibits
allocation from the main arena altogether in this specific case.

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, making the main arena
discontiguous after just one additional malloc()
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).
Maybe we should give up expecting a discontiguous main_arena to magically become
contiguous again, i.e. not call trim at all when the arena is marked noncontiguous.

BUT, taking a step back, is this really a serious problem?  I consider the
statement that "each call to free() incurs a system call" _false_, because libc
caches the last brk value, so sbrk(0) does _not_ perform a system call AFAICS.
Or are we talking about specific systems where sbrk(0) is just like sbrk(+x)?


-- 


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.