A lightweight thread is a Thread

[Alan Bateman]

This project has been trying to figure out the API to expose for 
lightweight threads, and its relationship with the Thread API, for some 
time. There has been many prototypes (lightweight thread = Thread, Fiber 
<: Thread, Fiber and Thread <: Strand, disjoint Fiber and Thread types). 
Thread.currentThread() and thread locals featured in all prototypes as 
it's critical that the current Thread cannot change value in a thread of 
execution.

I think we are at the point where we are concluding that a lightweight 
thread should be represented by a Thread. No Fiber or other sub-class 
exposed in the API. We'll use the term "lightweight thread" rather than 
"fiber". The approach maintains the mental model of a thread of 
execution that we are familiar with here, and the mental model that 
developers coming to the platform should be able to figure out. The 
Thread API does come with baggage (ThreadGroup, TCCL, ...) but it may 
not be too bad when you consider that most developers don't use the 
Thread API directly. In addition, we can degrade and/or eliminate at 
least some of this baggage over time, starting with the deprecated features.

Moving to Thread as the API for lightweight threads means we need to 
restart some of the API work. In particular the support for structured 
concurrency and cancellation will need to move aside temporarily as we 
rebuild from the bottom. I will push a change to the "fibers" branch 
soon with the first steps in that direction. The first steps include 4 
static factory methods on Thread to create lightweight threads 
(unnamed/named * default or BYO scheduler). There are several discussion 
points around what lightweight threads support and don't support. For 
now, the default is support thread locals and not inherit thread locals 
but it can overridden by specifying characteristics to the factory 
methods. The API is primitive for now and will likely change many times.

API aside, one of the benefits of representing a lightweight thread as a 
Thread is that it makes it possible to make progress in the 
serviceability areas that we've had to ignore to date. We can finally 
start to figure how the existing monitoring and management APIs, JFR, 
and diagnostic features might work with lightweight threads. Good 
progress has been made on JVM TI and the debugger support in the last 
year and it shouldn't require too much re-work to get the debugger 
support re-aligned.

One final thing for now is footprint.  There will be some refactoring of 
Thread required to reduce its footprint. The initial changes will move 
some of fields that aren't performance critical to a sidecar/helper 
object. Doug Lea has changes to the FJ code in the works that should 
avoid the need for padding/@Contended on the fields used by 
ThreadLocalRandom. The object size will, at least initially, be a bit 
larger that I had hoped but I'm sure we will improve this in time.

-Alan.