Re: extend dl-minimal malloc implementation

[Carlos O'Donell <carlos at redhat dot com>]

On 08/11/2017 08:44 AM, Florian Weimer wrote:
> On 08/11/2017 02:09 PM, Carlos O'Donell wrote:
>> I think we should push this upstream. It allows the full malloc API to be
>> used effectively instead of alloca.
>>
>> Are we worried about something?
> 
> I'm not sure we have consensus to move from alloca to malloc.  The IFUNC
> scheduler needs some allocator, but I'm no longer certain the minimal
> malloc will work for it because we are switching the malloc
> implementation as part of the relocation.
> 
> There is some code to ensure that the dynamic linker itself is relocated
> last, but I don't know how effective it is in practice.
> 
> I'm also concerned that without block merging on free, we can't return
> any allocated memory to the operating system once the initial relocation
> is finished.

Can we solve this by allocating an aligned block for the boostrap
allocator and maintaining enough of the same data structures that we can
have a "bootstrap arena" that *can* be handed to the non-bootstrap allocator?

I know we discussed this early on when looking at dl-minimal. How much work
would it be? We would need to maintain chunk structures, and at a minimum
terminate all the bins to empty, and use only one bin structure. It seems
like this should be doable. We don't need to coalesce, the future malloc
can do that.

Then we could use the bootstrap arena with minimal support, and eventually
free from it, and with correct accounting get 100% of it freed back to the
OS and we could monitor this. We would never allocate from this arena, and
we need not put it on the arena list / free list so it won't be used for
future allocations.

Thoughts?

c.