Quasar does preemptive scheduling, and even used to have time-slice based preemption. The latter was taken out as it proved to provide no benefit whatsoever, because processes that benefit from time-slice preemption are better off using the kernel's scheduler anyway, and the JVM gives them that option. Erlang has to do it because it only exposes a single scheduler. That's is still a strict subset of the JVM's capabilities.

> and the JVM gives them that option

By using java.lang.Thread?

Yep. Both Thread and Fiber are abstracted into a Strand. So Strand.currentStrand returns the current fiber/thread, Strand.sleep sleeps etc.. Locks and channels work with strands, too, so that both fibers and threads can synchronize on the same data, and even actors are assigned to a strand, so that an actor can run in either a fiber or a thread.

Then, you pick the strand implementation (lightweight or heavyweight) -- heavyweight for computation-heavy code like video encoding, lightweight for anything that blocks often -- and if you pick a fiber you can further select a particular scheduler, with the default being work-stealing (like in Erlang or Go), but you can plug your own (and control such stuff as CPU pinning for certain schedulers).

Why would you want your VM to implement time based pre-emption? That is the job of the kernel, which is very good at it.

Any JVM implementation is free to choose how to do it.