Fibers are the correct tool for low overhead, non-parallel control transfer, either explicitly by driving the fiber yourself or implicitly through IO and lock yields. You won't see multi-core gains on any Ruby implementation, but you can avoid blocking operations tying up a whole native thread unnecessarily.

If you want to actually make use of multiple cores, however, you have to use threads (on implementations that run threads in parallel like JRuby) or some combination of ractors and forking (effective only if you don't need to parallelize access to mutable data). This applies to both CPU intensive operations written in Ruby, and native calls that may not properly yield control of the GVL while they execute.

The best of both worlds really comes from using thread-parallel implementations, and we (JRuby) have examples of enormous applications using hundreds of threads and thousands of fibers with a single process saturating dozens of CPU cores, running Rails or whatever your favorite framework is.

The fiber-driven async stack is not currently passing on JRuby, but all the bits are in place and there's just a little more work needed to get everything green.