A lightweight thread is a Thread

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.