libc-alpha Digest 2 Mar 2018 10:59:55 -0000 Issue 6215

[Ondřej Bílka]

On Fri, Mar 02, 2018 at 11:48:09AM -0800, christopher.aoki@oracle.com wrote:
> 
> 
> > On Mar 2, 2018, at 2:59 AM, libc-alpha-digest-help@sourceware.org wrote:
> > 
> > From: Ondřej Bílka <neleai@seznam.cz>
> > Subject: Possible inline malloc alternatives: bitmap
> > Date: March 1, 2018 at 9:44:57 PM PST
> > To: libc-alpha@sourceware.org
> > 
> > 
> > Like I mentioned in other thread I plan to make improved malloc+friends.
> > It will be split to several aspects.
> > 
> > This one is about option to inline small size allocations which would
> > give same performance as using memory pool.
> 
> Is this option a proposal to inline functions in malloc(3)?
>

Yes
 
> Or is it a proposal to implement memory pools using a new
> API built on top of malloc(3) or some other API to handle
> the larger allocations?
> 
> If it is the former, would applications lose the ability to
> use a third-party malloc(3) implementation such as
> jemalloc(3)?
>

One would need to use version of inline allocator that would support
this inline API. For workloads with lot of small allocations any inlining
would give bigger performance boost than using another allocator.

Only real requirement to that is to use a provided mmap wrapper instead 
of mmap(and in case of fixed mmap you need also ensure that area with
metadata could be mmaped.

After that it suffices add function refill_buckets(x) that just return
result of malloc(x)

That is enough to work but inlines won't do anything because you didn't
give them any memory.

To take advantage of inlining third party allocator would need to fill
inline alloc buffers with chunks to be allocated.

For inline free it is about filling metadata and periodically collecting
freed chunks from that metadata. This could change as there is
alternative to call free when it collects specified number of chunks.

For bitmap this gives restriction on allocator to prefer spatial locality
instead of temporal one. With my previous generic linked list idea
inlining would be transparent as by constructing suitable linked lists it 
gives same addresses as original algorithm.