Virtual Threads: A Short Note about Naming

[Volkan Yazıcı]

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:

   1. 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.
   2. 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".

Best regards.

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

On Thu, Nov 21, 2019 at 1:07 PM Ron Pressler <ron.pressler at oracle.com>
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
>
>
>