On 13-07-04 10:54 PM, james wrote:
If the segments are allocated from a selection of standard sizes, can you not have a (hardware) thread-local pool for each size and dump to a shared pool?
No. We should be, but we've not moved to a single page-size pool yet. I hope to move to this design as well as a uniform-page-pool for the mostly-copying GC. But this is all a ways off.
Is it actually the allocation that is expensive, or is it the check to see if a new segment is needed?
The allocation and relatively complex logic around it. I think this could be simplified a lot, but it's very delicate and nobody's looked at it in a while.
The checks are a tax but they're pretty constant and CPUs can chew through them pretty fast.
How much would it hurt to lose a register in calls? If a function made a check on how much stack space there is remaining and it calls some further function, then it could typically tell that function how much space remains.
It's all done by comparing the stack pointer to a reserved segment register. The growth-prologue on x64 looks like this:
400b90: 64 48 3b 24 25 70 00 cmp %fs:0x70,%rsp 400b97: 00 00 400b99: 77 1a ja 400bb5 <main+0x25> 400b9b: 49 ba 08 00 00 00 00 movabs $0x8,%r10 400ba2: 00 00 00 400ba5: 49 bb 00 00 00 00 00 movabs $0x0,%r11 400bac: 00 00 00 400baf: e8 28 00 00 00 callq 400bdc <__morestack> 400bb4: c3 retq
When functions are inlined, are the stack checks all combined?
Yes.
It seems odd that the impact should be so high.
I agree that it's higher than it seems it "needs to be". But it will always be unnecessary overhead on x64; it really makes no sense there. The address space is enormous and it's all lazily committed.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
