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: Persistent malloc

On 11/07/2017 11:56 AM, Adrian May wrote:
> It worked fine until I tried it from multiple threads, at which point I
> fell foul of the arena-per-thread thing.
> It's not obvious to me from the sources how I could switch that off. I saw
> tunables called "arena test" and "arena max" but I'm not sure what they do.
> In _libc__malloc the per-thread fetching of the arena looks hard wired as a
> macro. I was hoping not to have to recompile libc incidentally.

man 3 mallopt


Gives you one arena, and all threads use that arena (main arena).

> Then again, what I really want is a pmalloc and pfree function so I can
> specifically request persistent allocation but default to the existing
> volatile per-thread stuff.

You can have whatever you are willing to design, implement, champion, and
support... this is an open source project driven by consensus :-)

> Could I just declare an empty malloc_state and pass it to int_malloc from
> pmalloc? Trouble is, in sysmalloc (dunno if that's relevant or not) I see
> (av != &main_arena) choosing whether or not to call MORECORE at all.


Only the main arena (arena 0) uses process heap, all other arenas use mmap.

> Is there any way to unravel these hard coded bits? Could I arrange for only
> pmalloc to use the main arena while the main thread has its own per-thread
> arena? Or is there some different pre-existing concept for how this kind of
> thing should be done?

You could arrange for a pmalloc to take chunks from the main arena only.

Such a thread would always have it's own thread-local cache (tcache) if you
don't bypass it.

It's hard to know what you want without some clear design document.


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