Re: extend dl-minimal malloc implementation

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

On 08/11/2017 09:06 AM, 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 take it your point is that because we process consolidation and shrinking
in malloc() instead of free() that we would need some special casing in free()
to handle the bootstrap arena removal.

Alternatively we could just add it to the free list with no attached threads?

If the structure is logically consistent it should be possible to put it
on the arena free list and let a thread grab it, and leave it to be handled
normally?

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

Allocating memory that can be marked read-only is going to require a new
internal API, and that will be used uniquely by the functions that need
to allocate such special memory regions that can be made RO/RW with
the special API.

Therefore I would argue that the question is orthogonal. We make malloc
a smooth transition from unrelocated/relocated so we can handle using
malloc/free for common uses in the loader.

If we need RO/RW memory we use another API, and that other API has to be
used to handle those memory regions.

Am I missing anything?

Cheers,
Carlos.