[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403201725.7509341f@MG>
Date: Thu, 3 Apr 2014 20:17:25 +0200
From: "M. Ziebell" <ziebell_marco@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: malloc & uncommitting memory
Am Thu, 3 Apr 2014 00:43:23 -0400
schrieb Rich Felker <dalias@...ifal.cx>:
> On Wed, Apr 02, 2014 at 05:08:05PM -0400, Rich Felker wrote:
> > As long as thresholds are chosen right, I don't think this approach
> > would be costly from a performance standpoint. But it might have
> > consequences for fragmentation. So I'd like to discuss it further,
> > see what ideas emerge, and whether it looks reasonable before
> > trying to implement anything.
>
> Basically, the way fragmentation can result from having "frozen"
> chunks is when small chunks adjacent to them are freed: these free
> chunks are unable to be merged with the frozen chunk, so they get
> reused for small allocations despite being adjacent to a large free
> (albeit frozen) region.
>
> I see several possible ways to reduce or avoid this:
>
> 1. Always leave large padding (large enough to stay in bin-63) on both
> sides of the frozen chunk when freezing. This would force adjacent
> freed chunks to get merged into a bin-63 chunk, preventing them
> from getting used for small allocations unless nothing smaller were
> available. However, they could still get used and gradually
> depleted.
>
> 2. When a chunk is freed, check if it's a neighbor to a frozen chunk,
> and if so, put it at the end of its bin rather than the beginning,
> so that other free chunks of the appropriate size get used first.
> However this wouldn't help when it's the only chunk of its size but
> another slightly-larger chunk would be a better candidate to split.
>
> 3. Allow merging directly into frozen chunks, the same way merging
> into free chunks is done now, with logic to expand the region
> that's PROT_NONE similar to the current logic for expanding the
> MADV_DONTNEED region.
>
> Of these, option 3 looks the most promising.
>
> Rich
As far as i understand "uncommitted" memory is allocated address space.
A region in memory which is not used by the program, but the address
space expanded to make a smaller region available to the programm for
use.
Please correct me if I am wrong.
Based on that understanding, the idea or your proposal sounds not
really desirable.
You have to take care of tons of exceptions and special cases.
I'm pretty sure I don't understand what uncommitted memory is for, but
I'm heary is hundreds of lines of complex code, if-else constructs
everywhere and bugs.
The way you suggest to manage these regions in memory sound pretty and
advanced, please don't feel offended by my statement.
Marco
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
