Scalable Stack Discuss
loongs-zhang opened this issue · comments
Stack Expansion
Trigger timing
Receive SIGSEGV/SIGBUS signal(necessary) or every suspend time, we calculate the size of the current SP to the low address on the stack. If this size is less than or equal to 25% of the stack size, the stack needs to be expanded.
How
- Yield the coroutine.
- Apply for a new stack that is twice the current stack size.
- Copy the stack frame by frame, and at this point, we need to modify the SP of the stack frame to point to the address of the new stack.
Stack Reduction
todo
https://photonlibos.github.io/docs/api/thread
Linux kernel already provided a on-demand memory mapping mechanism. Do we still need a scalable stack? That is a question.
stack_size refers to the size of the coroutine stack, default is 8MB, same as Linux default function size.
Be careful not to cause a stack overflow. Linux will report a stack overflow error at runtime. However, since Photon simulates the stack in user mode, it will not detect a stack overflow error immediately. Continuous access might cause the memory to be trampled. Normally, you should avoid write recursive functions.
Although we can use kernel's mprotect to guard this memory region, it will affect performance, so it is up to the user to control it.
The default stack is too large and wastes a lot. If adjust the default stack size, some scenarios can easily cause stack overflow. It is easy to think of a solution to manually transfer different stack sizes for different scenarios, but organizing business scenarios is not a simple task. Adding automatic expansion/reduction mechanisms can further liberate users.
@loongs-zhang Re-allocating stacks is not feasible, because many applications spread the addresses of stack-allocated objects to other parts of the code, and re-allocation implicitly makes the addresses invalid.
In fact, it's advised to just allocate a big enough stack at the beginning, and all modern OS kernels will delay the real allocation of the physical memory pages until they are actually accessed. This is a hardware-assisted way to scalable stack with an upper-bound.
If you don't actually use such large stacks, all you waste is only your virtual address space.
Fine.