Conversation

This is interesting and surely beneficial for specialized, Google-scale loads/HPC/massively-parallel processes with C++ style allocation patterns. But where a general purpose malloc is needed it's one of the worst possible designs. I hope it won't become the next jemalloc fad.

Quote Tweet

Dmitry Vyukov

@dvyukov

Feb 13, 2020

We open sourced tcmalloc! github.com/google/tcmalloc Includes per-CPU caching mode indispensable for highly-threaded servers&extensive huge page support. Lots of worthy things for low-level hackers. I contributed to it a bit incl cache capacity balancing github.com/google/tcmallo 1/2

Show this thread

Replying to

Are you not a fan of jemalloc? (I actually spent a little while recently trying to understand the core data structures and algorithms used in jemalloc but couldn’t find anything good and current describing them.)

Replying to

It's not that bad, but it has lots of tradeoffs for performance over memory usage and hardening.

Replying to

and

I think the data structures are similar to my mallocng or

@DanielMicay

's hardened_malloc, but with thread local cache, multiple arenas, and some massive alignment to locate metadata.

Replying to

and

(Hardened uses hash tables to locate meta; mine uses in-band path back to oob meta but validates that it round-trips.)

Replying to

and

It uses a hash table for allocations larger than > 128k but that may be switched to a data structure able to provide answers to range queries, at least by default, as part of implementing malloc_object_size. For slab allocations it just accesses the metadata based on slab index.

4:06 PM · Feb 13, 2020Twitter Web App