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: "kkylheku at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 18 Jul 2008 20:07:08 -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 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.