Updating the Wiki (Was: Virtual Threads: A Short Note about Naming)

[Volkan Yazıcı]

Hello,

Would any of the project members mind updating the project wiki
<https://wiki.openjdk.java.net/display/loom/Main>, please? I have attempted
to do it myself, but the wiki requires an account affiliated with one of
the OpenJDK projects. (I will be more than happy to maintain it, if I would
be granted necessary rights.) In particular, I was considering to address
the following issues:

   1. Rename "fibers" to "virtual threads" -- with some context into its
   reasoning and a link to the relevant mailing list discussion(s).
   2. Add a terminology section to share Ron's explanations (incl. links)
   on one-shot, multi-prompt, delimited, etc. keywords.
   3. Compile a collection of links to certain mailing list discussions,
   e.g., on naming, scoped variables, etc.

Updating the community via frequent conference presentations are really
appreciated. Some of us even go to the extent of following the mailing list
discussions to keep themselves up to date. That said, I think a central
resource to keep track of the project's last state is missing. (I presume
people are not expected to get that from OpenJDK sources.) Further, IMHO,
such a resource will also serve a historical track record of the project
too.

Best regards.

On Sun, Nov 24, 2019 at 11:47 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

> Knowing the many flavours of continuations is not at all necessary to
> understand Loom's continuations, let alone threads, but since you asked:
>
> * Asymmetric: When the continuation suspends or yields, the execution
> returns to
>   the caller (of Continuation.run()). Symmetric continuations don't have
> the
>   notion of a caller. When they yield, they must specify another
> continuation to
>   transfer the execution to. Neither symmetric nor asymetric continuations
> are
>   more powerful than one another, and each could be used to simulate the
> other.
>
> * Stackful: The continuation can be suspended at any depth in the
> call-stack,
>   rather than in the same subroutine where the delimited context begins
> when the
>   continuation is stackless (as is the case in C#). I.e the continuation
> has its
>   own stack rather than just a single subroutine frame. Stackful
> continuations are
>   more powerful than stackless ones.
>
> * Delimited: The continuation captures the execution context that starts
> with a
>   specific call (in our case, the body of a certain runnable) rather than
> the
>   entire execution state all the way up to main(). Delimited continuations
> are
>   strictly more powerful than undelimited ones (
> http://okmij.org/ftp/continuations/undelimited.html),
>   the latter considered "not practically useful" (
> http://okmij.org/ftp/continuations/against-callcc.html).
>
> * Multi-prompt: Continuations can be nested, and anywhere in the call
> stack, any
>   of the enclosing continutions can be suspended. This is similar to
> nesting of
>   try/catch blocks, and throwing an exception of a certain type that
> unwinds the
>   stack up to the nearest catch *that handles it* rather than just the
> nearest
>   catch. An example of nested continuations can be using a Python-like
> generator
>   inside a virtual thread. The generator code can do a blocking IO call,
> which
>   will suspend the enclosing thread continuation, and not just the
> generator:
>   https://youtu.be/9vupFNsND6o?t=2188
>
> * One-shot/non-reentrant: Every time we continue a suspended continuation
> its
>   state is mutated, and we cannot continue it from the same suspension
> state
>   multiple times (i.e we can't go back in time). This is unlike reentrant
>   continuations where every time we suspend them, a new immutable
> continuation
>   object that represents a particular suspension point is returned. I.e.
> the
>   continuation is a single point in time, and every time we continue it we
> go back
>   to that state. Reentrant continuations are strictly more powerful than
>   non-reentrant ones; i.e. they can do things that are strictly impossible
> with
>   just one-shot continuations.
>
> * Cloneable: If we are able to clone a one-shot continuation we can
> provide the
>   same ability as reentrant continuations. Even though the continuation is
> mutated
>   every time we continue it, we can clone its state before continuing to
> create a
>   snapshot of that point in time that we can return to later.
>
>
> - Ron
>
>
>
> On 23 November 2019 at 21:42:48, Volkan Yazıcı (volkan.yazici at gmail.com
> (mailto:volkan.yazici at gmail.com)) wrote:
>
> > Ron, really appreciated your elaborate answer. I will go further and
> kindly ask you to shed some light into certain terms you used in your
> explanation. Regarding the following paragraph:
> >
> > > ... 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, ...
> >
> > Would you mind explaining what do you exactly mean by
> > one-shot,
> > non-reentrant,
> > delimited,
> > symmetric & asymmetric,
> > multi-prompt,
> > cloneable,
> > stackful,
> >
> > please? (Additional references are more than welcome.) I definitely have
> some guesses and Google'd them, but aligning to your perspective, I
> believe, would help many others in the list, including me.
> >
> > Best.
> >
> > On Fri, Nov 22, 2019 at 12:24 PM Ron Pressler wrote:
> > > 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)(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
> > > > >
> > > > >
> > >
>
>