This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]