apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 49840] New: apr_allocator_max_free_set is broken with most malloc() implementations
Date Sun, 29 Aug 2010 07:55:26 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=49840

           Summary: apr_allocator_max_free_set is broken with most
                    malloc() implementations
           Product: APR
           Version: HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR
        AssignedTo: bugs@apr.apache.org
        ReportedBy: sf@sfritsch.de


Due to the way pools allocate and free memory from the allocator, the blocks
that are allocated last (and therefore have the highest addresses) tend to be
freed first. However, if max_free_index is set, the allocator will keep the
blocks that have been freed first in the free list and return the blocks that
have been freed last to libc with free(). This means that the memory blocks
with the highest addresses tend to stick in the free list. Therefore libc
malloc() implementations that use brk/sbrk can never return much memory to the
OS, because there are always blocks at the top of the address space still in
use.

An additional problem is that once a larger block has been put into the free
list, it can be kept there basically forever if this block size is not used
anymore. (The overwhelming majority of used blocks is 8k.) Therefore if such a
block has a relatively high address, it will prevent libc's malloc from
returning memory to the OS.


I haven't had a good idea yet how to solve this. One could use double linked
lists for the free lists and always free() blocks from the back end of the
list. But this would enlarge the overhead even in the case where max_free is
set to unlimited.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message