On 23/02/2018 3:04 PM, John Rose wrote:
On Feb 22, 2018, at 8:49 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
I don't think this request has any impact on Fibers at all. At any
given time a piece of executing Java code is executing on a current
Thread, and that current Thread must be running on a native thread
(regardless of mapping) and the native thread has an id. The only use
for exposing such an id is to allow you to correlate information
obtained from inside the VM, with information observed outside,
possibly by external tools.
We may or may not bind fiber identity to the legacy java.lang.Thread type.
I'm not assuming that exposing native thread ids implies anything about
the binding between those entities and anything higher-level. I have no
issue with a Fiber/Continuation/Task/whatever running on different
java.lang.Threads over its lifetime. For that matter I don't think it
matters if java.lang.Threads could execute on different native threads
(they don't but they could).
David
-----
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 method can return false if (a) Thread.current() reports the identity
of the OS thread (not the fiber currently running), and (b) the runnable
includes a blocking operation which causes the current fiber to reschedule
on a different OS thread before it returns.
Having this method return false is, perhaps, surprising enough to cause
us to inject fiber identity into java.lang.Thread, so that a
java.lang.Thread
identity is 1-1 with a fiber, rather than an OS "dinosaur" thread. (You can
only pick one!) The alternative is to keep a 1-1 identity between OS
threads
and java.lang.Thread instances, making a new type which carries fiber
identity that multiplexes in a scheduler-dependent way over OS threads.
It's an interesting trade-off, with many compatibility concerns.
I think we are leaning toward injecting fiber identity into Thread,
although this makes me shudder to think of the overheads we
will buy with this one move (ThreadLocal hash tables).
So, now if you reify the OS thread identity, you could have the same
issue again. Can this routine return false?
boolean testNTIDShift(Runnable r) {
long t0 = NativeThreadID.current();
r.run();
long t1 = NativeThreadID.current();
return t0 == t1;
}
I think, if you are digging down all the way to the native thread ID,
this routine *must* be allowed to return false under a Loom JVM.
There's no credible way to assign unique int64_t IDs to fiber objects
in the Java heap, as if they were OS objects.
So my question is, do the proposed use cases for NTID allow
for testNTIDShift to return false? If not, then it's pretty easy to say
that we don't want to supply NativeThreadID.current() for general
use, just to people implementing schedulers.
— John
