1. Transparency of the allocator’s implementation
Users wanted to see the actual code and contact the author.
- throwaway2037: “I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post.”
- joelsiks: “The exact implementation of mymalloc isn't relevant to the post. I have an old allocator published at https://github.com/joelsiks/jsmalloc…”
2. Practical ways to hook or observe malloc
The discussion compared several techniques, their safety, and ease of use.
- nly: “dlsym() with the RTLD_NEXT flag basically… There’s actually a better way to hook GNUs malloc… you can disable the hook inside the callback, and therefore use malloc within your malloc hook (no recursion).”
- Joker_vD: “The use of these hook functions is not safe in multithreaded programs, and they are now deprecated… Programmers should instead preempt calls to the relevant functions by defining and exporting malloc(), free(), …”
- jeffbee: “If you only wanted to observe the behavior the post is discussing, it seems like ltrace -e malloc is a lot easier.”
- fweimer: “You can still override malloc and call __libc_malloc if you do not want to bother with dlsym/RTLD_NEXT.”
3. Emergency‑pool configuration in libstdc++/glibc
Users debated whether the pool should be static, how to tune it, and its portability.
- Joker_vD: “Why is this emergency pool not statically allocated? Is it possible to tune the size of this pool on libc++ startup somehow?”
- joelsiks: “You can opt‑in for a fixed‑size statically allocated buffer by configuring libstdc++ with --enable-libstdcxx-static-eh-pool. You can also opt‑out of the pool entirely by setting GLIBCXX_TUNABLES=glibcxx.eh_pool.obj_count=0.”
- ninkendo: “Maybe it’s part of the whole ‘you only pay for what you use’ ethos, i.e. you shouldn’t have to pay the cost for a static emergency pool if you don’t even use dynamic memory allocation.”
- pjmlp: “This is compiler specific and cannot be generalised as C++.”