On 23/02/2018 05:04, John Rose wrote:
We may or may not bind fiber identity to the legacy java.lang.Thread type.
This affects the question of whether the following code can return false:
boolean testThreadShift(Runnable r) {
Thread t0 = Thread.current();
r.run();
Thread t1 = Thread.current();
return t0 == t1;
}
This is an area that I have been spending time recently. A big benefit
of a Thread object per fiber, and the above always returning true, is
that things that are thread local today (ThreadLocal, thread context
class loader, uncaught exception handler, ...) become fiber local
without too much effort. It means we have Thread objects that aren't
tied to a kernel thread or don't have thread meta data in the VM (the
lifecycle of Threads means we do this today anyway). Lots of details of
course but it's a direction that potentially allows a lot of existing
code to be executed in a fiber without changes.
In the java.lang.management API, ThreadMXBean is more tied to kernel
threads due to methods that reveal thread CPU counters. A possible
direction is to continue with a ThreadMXBean per dinosaur thread, in
which case Jeremy's proposal to expose the native thread identifier
might be okay. That direction would require sorting out a details with
the thread identifier (Thread::getId) as it can be used today to link a
Thread to a ThreadMXBean but that shouldn't be too hard.
-Alan.
