[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