Re: extend dl-minimal malloc implementation

[Florian Weimer <fweimer at redhat dot com>]

On 08/11/2017 04:18 PM, Adhemerval Zanella wrote:
> 
> 
> On 11/08/2017 10:06, Florian Weimer wrote:
>> On 08/11/2017 03:02 PM, Carlos O'Donell wrote:
>>> 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.
>>
>> If we never allocate from there, how would we achieve the goal of giving
>> back unneeded memory?
>>
>> I also think that in the long term, we should separate ld.so data
>> structures from the rest of libc, and even try to map keep read-only
>> most of the time (when dlopen is not running).
> 
> My understanding of this change it to 1. remove alloca usage in loader and
> 2. enable dynarrays and scratch buffers usage.  Do we care for interposable
> malloc on loader if we move to this direction of separate ld.so data?

No, the interface could even be different from malloc eventually (e.g.,
sized deallocation to reduce metadata overhead).

> Also, what about a specialized memory allocator for loader which a possible
> different signature than malloc? I think it would be feasible to extend
> both dynarray and scratch buffer to enable parametrize the malloc functions
> calls.

Right, that would be necessary if we ever switched to sized deallocation.

Thanks,
Florian