A lightweight thread is a Thread

[David Lloyd]

I like this idea!  It feels a lot less risky...

On Tue, Oct 22, 2019 at 9:00 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> 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.



-- 
- DML