This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libc-alpha Digest 2 Mar 2018 10:59:55 -0000 Issue 6215
- From: "christopher dot aoki at oracle dot com" <christopher dot aoki at oracle dot com>
- To: libc-alpha at sourceware dot org
- Cc: Chris Aoki <christopher dot aoki at oracle dot com>
- Date: Fri, 2 Mar 2018 11:48:09 -0800
- Subject: Re: libc-alpha Digest 2 Mar 2018 10:59:55 -0000 Issue 6215
- Authentication-results: sourceware.org; auth=none
- References: <1519988395.53274.ezmlm@sourceware.org>
> 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)?
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)?
If it is the latter, would the memory pool API provide a function
to release unused memory pool pages back to the underlying
large-page allocator?
Best Regards,
Chris Aoki