This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/18910] New: Free sub-heaps not in use to system timely
- From: "guo.gang.ye at sap dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 02 Sep 2015 09:27:22 +0000
- Subject: [Bug libc/18910] New: Free sub-heaps not in use to system timely
- Auto-submitted: auto-generated
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.