This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/18910] New: Free sub-heaps not in use to system timely


https://sourceware.org/bugzilla/show_bug.cgi?id=18910

            Bug ID: 18910
           Summary: Free sub-heaps not in use to system timely
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: guo.gang.ye at sap dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

For non-main arena, it is consisted of multiple sub-heaps, and sub-heap is
freed or returned to system only if it is the one where top chunk is in, and it
has no chunk be in used. So even there is one sub-heap it has no chunk be in
used (only one chunk and it is in free state), due to the design, the sub-heap
cannot be returned to system. This design issue cause unexpected memory usage
for a long running process which has hot memory usage(malloc/free).

Is it possible to do some enhancement? During trim event happen, try to check
any sub-heap not in use in current arena, event it is not the one where top
chunk is in, we still free it and return to system.

If do a malloc_info call for the long running process, there are lots of large
chunks or un-sorted chunks which have size 67108801 (very closed to
MAX_HEAP_SIZE, 64MB, minus meta data for chunk/heap and alignment). This
implies
the lots of unused sub-heaps, cannot return to system due to current design.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]