top | item 47205129

Why is the first C++ (m)allocation always 72 KB?

112 points| joelsiks | 11 hours ago |joelsiks.com

22 comments

order

anonymousiam|27 minutes ago

So basically, before any of the code even runs, this environment begins by gobbling up more than the total RAM that most of my first computers had (SYM-1, IAMSAI-8080, Ferguson Big Board, Kaypro II, and CCS S-100 Z-80). All of these systems were 8-bit, with various RAM sizes from 8KB to 64KB. That was the maximum RAM available, and it was shared by the OS and the applications.

pjmlp|6 hours ago

This is compiler specific and cannot be generalised as C++.

zabzonk|5 hours ago

Well, yes, but still quite interesting, IMHO. It's not like GCC is one of the least used compilers.

compiler-guy|6 hours ago

And C++ library specific as well. Perhaps even more so.

cendyne|26 minutes ago

This was a fun little share. Thanks for writing it up!

jebarker|3 hours ago

Reading this was a good reminder not to be intimidated by assumptions about complexity. (Without giving it much thought) I would have assumed that it would be hard to replace malloc for such fundamental applications as ls, but it's surprisingly simple.

syncsynchalt|2 hours ago

There's usually an easy-ish way to override malloc/calloc/realloc/free on Unix, as it's very useful to do when debugging issues or just to collect allocation metrics.

In ELF objects (i.e. on Linux) this is usually done with the "Weak" symbol binding. This is an optional flag for symbols in ELF format that let you override a symbol by providing a competing non-weak symbol, which the linker will prefer when there is a conflict. https://en.wikipedia.org/wiki/Weak_symbol

You can see the list of Weak symbols by looking for a 'W' in the output of `nm` on linux hosts.

Joker_vD|8 hours ago

Huh. Why is this emergency pool not statically allocated? Is it possible to tune the size of this pool on libc++ startup somehow? Because otherwise it absolutely should've been statically allocated.

joelsiks|7 hours ago

I did mention it briefly in the post, but you can opt-in for a fixed-size statically allocated buffer by configuring libstdc++ with --enable-libstdcxx-static-eh-pool. Also, you can opt-out of the pool entirely by configuring the number of objects in the pool to zero with the environment variable GLIBCXX_TUNABLES=glibcxx.eh_pool.obj_count=0.

throwaway2037|9 hours ago

I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post. Nor do I see anything in his GitHub profile: https://github.com/jsikstro

Also, I cannot find his email address anywhere (to ask him to share it on GitHub).

Am I missing something?

joelsiks|9 hours ago

The exact implementation of mymalloc isn't relevant to the post. I have an old allocator published at https://github.com/joelsiks/jsmalloc that I did as part of my Master's thesis, which uses a similar debug-logging mechanism that is described in the post.

aliveintucson|5 hours ago

I think you should read up on what "always" means.

znpy|5 hours ago

> TLDR; The C++ standard library sets up exception handling infrastructure early on, allocating memory for an “emergency pool” to be able to allocate memory for exceptions in case malloc ever runs out of memory.

Reminds me of Perl's $^M: https://perldoc.perl.org/variables/$%5EM

In Perl you can "hand-manage" that. This line would allocate a 64K buffer for use in an emergency:

    $^M = 'a' x (1 << 16);