[patch v2] malloc: avoid need for tcache == NULL checks

Wilco Dijkstra Wilco.Dijkstra@arm.com
Mon Sep 1 12:59:31 GMT 2025


Hi DJ,

>> I suppose these could be inline functions instead of macros.
>
> That's been suggested in the past, and IIRC my reply was "why?"
> Changing these to functions just makes the file longer, it doesn't
> change the generated code.  And, I like having all the related macros
> together like that instead of spread across multiple pages.

The main advantage is that one can add checks in inline functions or make
changes without ending up with complex multi-line macros.

> OTOH maybe it's time to clean up the organization of the malloc sources?
> The main file is too big and the helper files are too small, and arena.c
> is an include(?) instead of a standalone file, etc.  If stuff were more
> organized, the extra whitespace functions-vs-macros would add would be
> less of a problem.

Agreed. The hard part is that everything depends on everything else and there
are lots of inline functions, so it's non-trivial to pull apart cleanly.

> Could this be moved to the
>
>>    if (SINGLE_THREAD_P)
>>      {
>>        victim = tag_new_usable (_int_malloc (&main_arena, bytes));
>> @@ -3427,8 +3455,6 @@ __libc_malloc (sizer_t bytes)
>>    if (nb < mp_.tcache_max_bytes)
>>      {
>>        size_t tc_idx = csize2tidx (nb);
>> -      if(__glibc_unlikely (tcache == NULL))
>> -	return tcache_malloc_init (bytes);
>
> tcache path here?

> No, I had to move it outside the code that takes the lock, else it would
> soft-lock in tcache_init when it too calls malloc.

We could just pass the arena to tcache_init(). Moving it later and closer to code
that uses tcache might well be better.

Cheers,
Wilco


More information about the Libc-alpha mailing list