4 ms·
Go depends on the fact that it can track all pointers, and when it needs to resize stacks, it can update them. Previous versions of Go used segmented stacks, w
by lukaslalinsky 1y ago
Go depends on the fact that it can track all pointers, and when it needs to resize stacks, it can update them.
Previous versions of Go used segmented stacks, which are theoretically possible, if Zig really wanted (would need compiler support), but they have nasty performance side-effects, see https://www.youtube.com/watch?v=-K11rY57K7k https://www.youtube.com/watch?v=-K11rY57K7k
- loeg 1y agoResizing stacks on use does not depend on any of these properties of Go. You can do it like this in C, too. It does not require segmentation.
- lukaslalinsky 1y agoI'm very interested to know how. Do you mean reserving a huge chunk of virtual memory and slowly allocating it? That works to some degree, but limits how many coroutines can you really spawn.
- loeg 1y agoYes, exactly.
- boomlinde 1y agoResizing stacks insofar that expansion may require moving the stack to some other place in memory that can support the new size depends on these properties. Your initial 4k of coroutine stack may have been allocated some place that wont fit the new 8k of coroutine stack. Or are you making a point about virtual memory? If so, that assumption seems highly platform dependent.
- loeg 1y agoYou would implement this with virtual memory. Obviously, this is less of a limited resource on 64-bit systems. And I wouldn't recommend the Go/stack/libtask style model for high concurrency on any platform.