Thread Native ID Access

[Alan Bateman]

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.