Bug #21964
Updated by ioquatix (Samuel Williams) 25 days ago
In several common scenarios, the fiber stack allocator can choose to expand the fiber stack pool even when there are unreachable (effectively dead) fibers.
For example, the following program will eventually crash if GC does not run in time:
```ruby
loop do
Fiber.new{Fiber.yield}.resume
end
```
We have a loop that resumes a fiber, that fiber yields, and then becomes unreachable. Eventually, we will exhaust the OS vm map limit and fail with `FiberError`. However, at most only one fiber (stack) is needed to execute the above program, since the fiber immediately becomes unreachable.
To fix this, we run GC before trying to expand the fiber stacks: https://github.com/ruby/ruby/pull/16535 - this PR also fixes a minor memory leak on the failure path of expanding the fiber pool. stacks.
In practice, fiber stacks are expanded on power of 2, up to 1024 fibers per allocation. So GC is only run in scenarios where we hit this limit. If GC is running normally, or fibers are terminating normally, we may never hit this code path.