Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
Re: extend dl-minimal malloc implementation
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 shrinkingin 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 iton the arena free list and let a thread grab it, and leave it to be handlednormally?> 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 newinternal API, and that will be used uniquely by the functions that needto allocate such special memory regions that can be made RO/RW withthe special API.Therefore I would argue that the question is orthogonal. We make malloca smooth transition from unrelocated/relocated so we can handle usingmalloc/free for common uses in the loader.If we need RO/RW memory we use another API, and that other API has to beused to handle those memory regions.Am I missing anything?Cheers,Carlos.
[8]ページ先頭