Virtual Threads: A Short Note about Naming

[Ron Pressler]

Loom’s virtual threads are not coroutines under any common definition of that
name. Coroutines are one-shot (non-reentrant) delimited continuations, and, at
least in the past, they were sometimes used to refer to *symmetric* one-shot
delimited continuations, although they have been used to refer to assymetric
delimited continuations as well. The continuations used under the cover to
implement Loom's virtual threads are multi-prompt, one-shot -– although possibly
cloneable -- stackful, assymetric, delimited continuations (yeah, continuations
come in many flavors). It is possible we'll decide to call those continuations
coroutines, although in recent years the name coroutines gained a connotation
that identifies it with a particular implementation of continuations as special
syntactic constructs in the language (such as async in C# or suspend in Kotlin).
But in any event, coroutines always refer to continuations (Go's goroutines, a
pun on coroutine, does refer to threads).

Threads are a continuation plus a scheduler, or scheduled continuations, and
therefore Loom's user-mode threads are threads, and whether or not we decide to
call Loom's continuations coroutines, the name is inappropriate for scheduled
entities.

The name is not only technically inappropriate, but suffers from all the same
problems "fiber" does, and then some. It sounds like a whole new concept people
have to learn, it is heavily overridden elsewhere to refer to somewhat similar,
yet substantially different, concepts, and it doesn't even evoke a conceptual
similarity to threads.

As to your two questions, I'll address them more specifically inline, below:



On 22 November 2019 at 08:47:13, Volkan Yazıcı (volkan.yazici at gmail.com(mailto:volkan.yazici at gmail.com)) wrote:

> As someone who is far from comprehending the implications of concluding on a certain nomenclature for Project Loom deliverables, I am having difficulty in understanding why don't we just call "this" as "coroutines". In a discussion between you and Jonathan Brachthäuser(http://mail.openjdk.java.net/pipermail/loom-dev/2018-September/000141.html), you had shared some more insight into the reasoning behind the back then naming conventions. There you had also hinted that you may decide to change the name to "coroutine". Regarding this and the aforementioned discussion, I have two questions:
> In statement "more recently [coroutine] has gained the connotation (not in academic literature but in language implementations) of being a syntactic construct, rather than a purely dynamic one" of yours, would you mind elaborating on what do you exactly mean by a "purely dynamic one"? I see that C++20 and other coroutine-providing PLs require explicit syntactic sugar to denote suspendable-and-resumeable subroutines. But apart from this explicit denotation requirement, isn't Loom delivering almost the same thing? Further, Loom also enforces its own explicit requirements (i.e., subroutine needs to be wrapped in a "virtual thread"), which "feels" similar to me from a developer perspective.

That explicit syntactic denotation is no small matter. It is the reason languages
with that kind of continuations cannot unify the concept of suspension and blocking
even though the only difference between the two is whether suspension is implemented
by operating system or by the language. A language like, say, JavaScript needs two 
separate IO APIs, one blocking and one suspending, or asynchronous, even though the
two may have the exact same denotation in the language. Languages like C#, Rust and
Kotlin even separate the two in the type system. That in Java suspending a continuation
does not require any different type, or any other syntactic notation whether the
operation is performed by the kernel or the language is an essential feature. So the
languages I mentioned syntactically separate a concept based on its particular 
implementation, but Java (like Erlang, Scheme and Go) doesn’t. Loom's virtual threads
*are* threads; why focus on the implementation rather than the abstraction especially
when we don’t make any syntactic distinction between them?

> To the best of my knowledge, Melvin Conway's 1958 definition of "coroutines" basically boils down to good old subroutines with suspend and resume support. From this angle, I feel inclined to call Loom "virtual threads" as "coroutines". The latter term might indeed be tainted by modern times, but I believe Java has enough leverage and resources to rinse it off. This will also imply a PR for Java in the sense of "better coroutines" addressing all the catches and limitations imposed by, say, Kotlin, Quasar, Kilim "coroutines”.

As I said above, Loom’s threads are not coroutines, but coroutines + scheduler. The
common name for coroutines + scheduler, for many years, has been "thread."

> Best regards.  
>  
> P.S. Thanks for updating the community on these internal changes and letting us get engaged in discussions.


- Ron

>  
> On Thu, Nov 21, 2019 at 1:07 PM Ron Pressler wrote:
> > We started with fibers. Then we found out that people think it's a new concept
> > they have to learn (which is further complicated because "fiber" is used to
> > refer to superficially-similar-yet-essentially-different concepts elsewhere)
> > rather than just a user-mode implementation of threads. The different name then
> > became even less justified when we started representing our user-mode threads as
> > java.lang.Thread. We then considered "lightweight threads." The problem with
> > giving an absolute name to a relative concept is that one day we may have
> > threads that are even lighter-weight than lightweight threads, and what would we
> > call those? "User-mode threads" is correct but perhaps too technical. So we're
> > going with "virtual threads." The name is intended to evoke the similarity of
> > the relationship our usermode threads have with kernel threads to that between
> > virtual and physical memory. The name has the advantage of familiarity on one
> > the one hand as well as not clashing with potentially confusing
> > similar-but-not-quite usages on the other. A test run of "virtual threads" at
> > Devoxx looked promising.
> >  
> > - Ron
> >  
> >