The push_back() semantics features the standard array doubling technique, but only up to 4 KB; jemalloc can't grow in-place anything smaller than this, so a copy is required. Beyond that cut-off, push_back() will instead grow by 1.5 times the capacity to prevent too much "slack" memory from accumulating.
I could understand why you would object to both, but why only the lower level language.
Are you getting confused between tptacek and me?
I recently created a private memory allocator so the discussion on the page is somewhat interesting...
Only a tiny minority of objects are genuinely non-relocatable:
Hmm, I'm not exactly what is meant here. Moving a block of memory from here to there in the most general case will leave your pointers dangling and crash you in no short order. Things that pointed to the data you moved just don't any more. If you are disciplined and don't have raw pointers in the block moved, you're good. But as far as I know, that situation requires a very complete understanding of the data in the block you are moving. You can do that. It's just not easy or something that makes sense to stuff "anything" into.
std::string is a key exception to this, but fbstring is not.
In addition, it does not support concurrent growth.
- It requires that its members be relocatable and uses memmove to speed up move operations.
https://github.com/facebook/folly/blob/master/folly/docs/FBV...