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();
  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.


Reply via email to