Introduction, JRuby needs
Charles Oliver Nutter
headius at headius.com
Mon Feb 5 14:00:02 UTC 2018
Hello!
I saw Ron's talk at the JFokus VM Summit today, and I am very excited to
see this work finally happening.
I've been working on JRuby for many years, and one of the biggest problems
we have getting users from CRuby is the cost of fibers. Because we have too
many dynamic call paths through JRuby, we've never been able to use
something like Quasar, and even if we could it doesn't compose well with IO
-- the most compelling use case for fibers in Ruby. Unlike Python's
generators, Ruby's fibers can be yielded at any time -- potentially deep in
a call stack -- so we can't simply weave a continuation into the bytecode.
Our only option has been to back fibers with native threads, so it becomes
essentially impossible to support tens or hundreds of thousands of fibers
all active at the same time.
I have a few notes from my experience on JRuby and from watching Ron's talk.
* synchronized and Object.wait
Rom brought these up as potential problems, since as lowish-level locking
operations, they would currently cause a continuation to block whatever
native thread was driving it. My thought here is that A: this is largely
expected behavior for Ruby fibers (if you make any non-fiber-aware blocking
call, the fiber can't be deferred) and B: it's reasonable to expect that
libraries get reworked to use concurrency primitives like j.u.c.l.Lock.
* GC behavior?
I forgot to ask this during the talk, but I'm hoping it's a non-question:
incomplete coroutines that get dereferenced need to be gracefully cleaned
up by the GC. This was a particularly difficult part of the current JRuby
fiber implementation since the native thread driving it could hold no
direct references to the user-facing Fiber object. Hence, we have to use
finalizers or phantom references or similar to allow abandoned fibers to
die gracefully (if you call a finalizer that kills a thread graceful). I
admit I have not read through the full proposal yet...I shall.
* Timeframe? How can I help?
We are very eager to start playing with this, and my understanding is that
parts of the prototype already work. A key part, actually yielding control,
may come soon. I'd like to hear a bit more about expected timeframes, and I
very much want to help things move along. I promise once we get a proper
yield implemented, I'll build a JRuby that uses them.
Super exciting times!
- Charlie
--
- Charlie (mobile)
More information about the loom-dev
mailing list