Virtual Threads: A Short Note about Naming
cay.horstmann at gmail.com
Thu Nov 21 18:51:10 UTC 2019
I agree that naming is important. Not sure "virtual" is a winner because
it has connotations of increased cost.
Virtual memory invokes nagging thoughts about paging and cache misses.
Virtual functions are more expensive to call than plain old functions
because they can't be inlined. (Except speculatively in the JVM :-))
"User-mode" is not necessarily better than "lightweight". Those yet
unknown even lighter-weight threads that the future may bring could
still be "user-mode".
That's where "strand" or "fiber" is handy. But if you think those are
tainted, you could try a new term like "threadlet" or "blue thread".
Il 21/11/19 13:07, Ron Pressler ha scritto:
> 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
More information about the loom-dev