3 ms·
But you can allocate large stacks efficiently too. Is this something specific to how GC works? Edit: Is it about having stacks smaller than a page, maybe not
by SamReidHughes 11y ago
But you can allocate large stacks efficiently too. Is this something specific to how GC works?
Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?
- pcwalton 11y agoIn general mallocs allocate small blocks a lot faster than they allocate large blocks, because small blocks qualify for free list binning and the OS kernel doesn't need to serve you as many pages. (It wasn't obvious to me either that this was the case, but try it and see for yourself!) :)
- SamReidHughes 11y agoAt RethinkDB we managed our own free lists for stacks for this reason. One funny problem with the first implementation was that a stack could be born on one posix thread and die on another -- and certain threads would accumulate all the stacks, while the others would keep allocating them fresh.
- pcwalton 11y agoYeah, caching works OK when your total thread count is relatively constant, but most thread spawning benchmarks do things like spawn 100000 threads, synchronize, and then shut them all down, in which case the thread high-water-mark is constantly increasing and your stack cache always misses.
- SamReidHughes 11y agoCould you find out the names and addresses of people making these benchmarks? If so, that seems like it would be a relatively easy problem to fix. (Edit: I mean of course so we could allocate memory at their addresses for better locality, this is HN after all. Other ideas would need to be pulled to a different arena.)
- deleted 11y ago[deleted]