[PATCH] malloc: retire mechanism for older non used tcached chunks
Wilco Dijkstra
Wilco.Dijkstra@arm.com
Sat Dec 20 16:57:28 GMT 2025
Hi Cupertino,
So I'm not sure how the algorithm could work. On a free, you no longer
limit the number of chunks that can be inserted into the freelist. Instead
tcache_location_large first moves any out of date blocks to the
return_to_arena list and only then checks the count of the current tcache
bin. So doesn't that mean you can end up adding an unlimited number of
blocks into the return_to_arena list without ever cleaning it? To make things
worse, the default value of tcache_retire_size is set to 0 which means any
freed block is considered out of date by definition...
Also this adds a large overhead since you always check for out of date blocks
during every free/malloc of a large block. If we only call tcache_large_cleanup
if a large bin is full or empty, and then need the RETIRE_OLD_CACHED_CHUNKS
scan, doesn't it make more sense to do this only in tcache_large_cleanup?
That way you avoid all the overheads and only do some extra work if the bin
is full or empty. Also don't you need to do a full scan of all bins every now and
again anyway? Blocks can only get added to return_to_arena if there is a
deallocation into that bin - if there isn't, blocks will forever stay in unused bins.
So I'm wondering whether doing this when a bin is full/empty will work at all.
Wouldn't it be simpler to use an allocation counter and if it goes below zero
flush the current bin, and every now and again flush everything?
In terms of implementation, there is a huge amount of special case code
being force inlined into the fast paths, including adding lots of calls. This is
terrible for performance - even for the small bins. The correct approach is to
call a no-inline function to handle the special cases outside the fast paths.
Cheers,
Wilco
More information about the Libc-alpha
mailing list