[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