This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead
- From: "bugzilla1 at malloc dot de" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 28 Mar 2008 17:44:58 -0000
- Subject: [Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead
- References: <20050727134634.1128.jp-www@dcs.gla.ac.uk>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.