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

Cupertino Miranda cupertino.miranda@oracle.com
Fri Apr 11 21:58:53 GMT 2025


Hi DJ,

Got it, makes sense. ;-)
Did not thought about it delaying the frame construction to the inner call.
Nice optimization technique!

Cheers,
Cupertino

On 11-04-2025 22:25, DJ Delorie wrote:
> Cupertino Miranda <cupertino.miranda@oracle.com> writes:
>> 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.
> 
> If __libc_malloc is simple enough, it can be built without a call frame
> at all, saving many opcodes of execution time.
> 
> If you inline more code "at the bottom" that has the effect of moving
> all the call frame code into the hot path, because now you need a full
> call frame (assuming, correctly in this case, that the extra code would
> warrant a call frame).
> 
> Illustrated:
> 
> __libc_malloc:
> 	cmp $eax,0
>          je 1f
>          call tcache_get
>          ret
> 1f:
>          jmp __libc_malloc2
> 
> __libc_malloc2:
> 	... lots of setup ...
>          ... rest of code ...
>          ... lots of tear-down ...
>          ret
> 
> If you inlined it, you'd end up with:
> 
> __libc_malloc:
> 	... lots of setup ...
> 	cmp $eax,0
>          je 1f
>          call tcache_get
>          ret
> 1f:
>          ... rest of code ...
>          ... lots of tear-down ...
>          ret
> 
> 
> Note that the "lots of setup" is now in the hot path.
> 



More information about the Libc-alpha mailing list