This is the mail archive of the
mailing list for the glibc project.
Re: extend dl-minimal malloc implementation
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
Right, that would be necessary if we ever switched to sized deallocation.