Cooperative vs preemtive scheduling of virtual theads

[Alan Bateman]

On 06/06/2020 16:16, Andrey Lomakin wrote:
> Hi,
> I have started to develop a prototype of the project which was based on
> earlier versions on quasar and now on early builds of Loom JDK.
If you have time, it could be useful if you could share your experiences 
using the EA builds. Did you run into any problems or issues, was the 
performance okay, any other observations to share?


> According
> to the paper which describes the state of the Loom project even though now
> virtual threads use only cooperative scheduling, it is considered to use
> forced preemption during some conditions.
> My problem is that cooperative preemption is much more useful for me. My
> project based on the approach, that different components of the project do
> not share data, and each component instance handles requests inside of
> dedicated single thread executor, which schedules virtual threads. Knowing
> when exactly you need to care about concurrent execution of the virtual
> threads allows to create faster code and use data structures and algorithms
> which you will not be able to use in other cases.
> So my question is, according to your perception of the current state of the
> project, how is it possible that forced preemption will be introduced as
> default behaviour? And will it be possible to switch it off by providing
> options during the start of the JVM? Sure, that situation could be changed
> during the development of the project. But I would like to hear your
> opinion.
Virtual threads are pre-emptive, the scheduling points are locking or 
blocking I/O operations. It's not cooperative in the sense that there 
isn't the equivalent of an "await" in other languages. If I read your 
message correctly, your concern is the the "Forced Preemption" section 
in the Futures/Part-2 of State of Loom. There is some low-level support 
in the current prototype that uses the the thread-local handshakes 
mechanism in the HotSpot VM. It's not exposed or used at this time and 
very much a "TBD" if/how it might be exposed to custom schedulers. So 
nothing to be concerned with right now.

-Alan