Cassandra already does this[1] (and a whole lot more besides to introduce chaos to the simulation), and just accepts that there's a huge penalty of pausing and scheduling threads.
I'm really looking forward to being able to use Loom to run much more efficient cluster simulations.
What sort of performance characteristics does Cassandra see from its implementation? I was fairly impressed with the 2.5M context switches per second (a fairly random unit, I know) I saw from virtual threads.
Have you found that the approach has made it easier for you to ship improvements to Cassandra?
It's very slow, particularly since introducing byte weaving to introduce chaos in concurrency-sensitive places. Presently it takes a single thread in the region of twenty minutes to simulate a cluster from startup to shutdown, and to run a thousand linearisable operations (down from a couple of minutes prior to those changes). I haven't got any numbers on the rate of context switches per second, but it is certainly a great deal less than 2.5M/s.
This kind of approach is in my opinion a _requirement_ for work on distributed consensus protocols, which the Cassandra community is improving at the moment: the upcoming 4.1 release has some major improvements to its Paxos implementation that were validated by this simulation, and the following release is expected to contain a novel distributed consensus protocol we have named Accord, for supporting multi-key transactions.
So, I'm not sure it has affected the speed or ease of shipping improvements, rather than enabled a class of work that would have previously been impossible to do safely (IMO).
I'm really looking forward to being able to use Loom to run much more efficient cluster simulations.
[1] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10...