Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

joelsiks.com

Post reply on HN
Print view View original

11–20 of 39 posts

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

#11

Post by ninkendo »

joelsiks wrote: post #7
Joker_vD wrote: post #6

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.

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.

I wonder why it’s opt-in. 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.

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

#15

Post by znpy »

> 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

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

#16

Post by pjmlp »

zabzonk wrote: post #12
pjmlp wrote: post #9

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

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

Yeah, but that isn't C++ in isolation, thus the tile is incorrect.

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

#17

Post by jeffbee »

nly wrote: post #8
Joker_vD wrote: post #5

Earlier quoted context omitted.

The use of these hook functions is not safe in multithreaded programs, and they are now deprecated. From glibc 2.24 onwards, the __malloc_initialize_hook variable has been removed from the API, and from glibc 2.34 onwards, all the hook variables have been removed from the API. Programmers should instead preempt calls to the relevant functions by defining and exporting malloc(), free(), realloc(), and calloc().

Yeah. Shame though because it gave you the option to control exactly when you hooked and didn't hook, which let stop and start debugging allocations based on arbitrary triggers. The global variable approach was very useful and pretty low overhead.

If you only wanted to observe the behavior the post is discussing, it seems like `ltrace -e malloc` is a lot easier.

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

#18

Post by fweimer »

nly wrote: post #8
Joker_vD wrote: post #5

Earlier quoted context omitted.

The use of these hook functions is not safe in multithreaded programs, and they are now deprecated. From glibc 2.24 onwards, the __malloc_initialize_hook variable has been removed from the API, and from glibc 2.34 onwards, all the hook variables have been removed from the API. Programmers should instead preempt calls to the relevant functions by defining and exporting malloc(), free(), realloc(), and calloc().

Yeah. Shame though because it gave you the option to control exactly when you hooked and didn't hook, which let stop and start debugging allocations based on arbitrary triggers. The global variable approach was very useful and pretty low overhead.

You can still override malloc and call __libc_malloc if you do not want to bother with dlsym/RTLD_NEXT. These function aliases are undocumented, but for a quick experiment, that shouldn't matter.

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

#19

Post by appreciatorBus »

pjmlp wrote: post #16
zabzonk wrote: post #12

Earlier quoted context omitted.

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

Yeah, but that isn't C++ in isolation, thus the tile is incorrect.

Article has been updated

> EDIT (March 1, 2026): I updated the title to to clarify that this observation is specific to my environment. The original title may have implied a universal behavior, which isn’t the case. Thanks for the feedback!

Post reply on HN