This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Mel Gorman <mgorman at suse dot de>, libc-alpha at sourceware dot org
- Date: Wed, 11 Feb 2015 12:10:39 +0100
- Subject: Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead
- Authentication-results: sourceware.org; auth=none
- References: <20150209140608 dot GD2395 at suse dot de> <54D91E06 dot 7060603 at redhat dot com> <54D9F9E6 dot 6050606 at redhat dot com> <54DA1C04 dot 5030001 at redhat dot com>
On 02/10/2015 03:56 PM, Carlos O'Donell wrote:
> On 02/10/2015 07:30 AM, Florian Weimer wrote:
>> On 02/09/2015 09:52 PM, Carlos O'Donell wrote:
>>> On 02/09/2015 09:06 AM, Mel Gorman wrote:
>>>> while (data_to_process) {
>>>> buf = malloc(large_size);
>>>> do_stuff();
>>>> free(buf);
>>>> }
>>>
>>> Why isn't the fix to change the application to hoist the
>>> malloc out of the loop?
>>
>> For a lot of C++ code, this would require replacing global operator new
>> with a pool allocator. We do not want programmers to do that, for
>> various reasons (loss of tooling, our limited malloc hardening, etc.).
>
> Is this because the objects are implicitly allocated by the language
> in the inner loop using new?
Not by the language, but by libraries. The libraries may not offer a
choice to avoid the large allocation and deallocation. In general,
object reuse is no longer considered good design because it typically
complicates the different states an object must support. This is
probably not specific to C++, it may affect modern C code as well (which
tends to hide implementation details with pointers to incomplete structs
etc., and not rely on callers providing sufficiently sized buffers).
Even if there is a way to reuse objects (e.g., we have freopen in
addition to fopen/close), I don't want to suggest it to developers
because it eventually leads to custom allocators, pools and the problems
that come with them.
--
Florian Weimer / Red Hat Product Security