[PATCH] malloc: move tcache_init out of hot tcache paths

[Cupertino Miranda]

Hi Wilco,

On 11-04-2025 21:05, Wilco Dijkstra wrote:
> Hi Cupertino,
> 
>>> This is reasonable until we inline this into calloc and use the same
>> approach as malloc.
>> Sorry, can not understand what you mean.
>> If your suggesting to call this function from calloc, why would it be a
>> problem ?
> 
> It's not a problem, the idea is to do same changes as done on malloc.
Ok.
> 
>>> This causes a slowdown as this is adding a call to __libc_malloc.
>>> See https://sourceware.org/pipermail/libc-alpha/2025-April/165720.html for
>>> a better way to do this.
>> What call are you refering to? Please notice that I just move
>> MAYBE_INIT_TCACHE.
> 
> The macro hides an if statement and call. I moved it to __libc_malloc2 in a
> previous commit so it does not force a frame and associated overheads.
I know it does, however I am moving that check and call after the tcache 
hot path, meaning that if tcache is initialized and there is a chunk 
available in the cache, it will not even reach the MAYBE_INIT_TCACHE 
check and call.

I must admit, I still cannot understand why __libc_malloc2 being a tail 
call would be preferable then copying the content of __libc_malloc2 at 
the end of __libc_malloc, or even __always_inlining it.
I believe inlining does not force a new (stack) frame for the inlined 
function, it is just as if the function would not exist and its source 
code content would be copied to the caller location, right?
I suspect that if you do not set __attribute_noinline__ in 
__libc_malloc2 the compiler would still inline it, as it is the only 
location where __libc_malloc2 is called, sort of proving the point.

All this considering there is no special hardware feature that would 
somehow make tail calls preferable. In my head, no calls, even if 
implemented with an unconditional jump (as in tail calls) is always 
preferable.

> 
>> Right, I honestly forgot about possible threads that only free.
>> On the other hand, in the case they only free, what is the point of caching?
> 
> Not much, and if a thread never allocates then it might even be counter
> productive as DJ mentioned. It just seemed unintentional since it's not
> mentioned. If you mention it in the description then it would be fine.
Well, I might not have explicitly mentioned it, but the intention was 
there. I did not omit the call to tcache_init in free by mistake.
> 
>> In my head, it only makes sense to cache after it starts to allocate data.
>> If it is a thread start there will be nothing in the tcache, so malloc
>> will always need to happen through arenas, and will initiate tcache there.
> 
> Yes typically malloc would be called first.
I will prepare a v2 of the patch, removing the non required checks and 
further verbosing the commit message.
> 
> Cheers,
> Wilco

Cheers,
Cupertino