I think we're all pretty much agreed that fibers imply native tids can change. I think that, as long as we document that, we're fine.
An API where there is probably a worse implementation problem is ThreadMXBean#getThreadCpuTime <https://docs.oracle.com/javase/9/docs/api/java/lang/management/ThreadMXBean.html#getThreadCpuTime-long->. Right now, the implementation assumes a 1:1 mapping between OS thread and Java thread. Removing that assumption implies you have to do something like track cpu time every time the scheduler switches you out, which is going to make your switches expensive. Jeremy On Thu, Feb 22, 2018 at 9:16 PM, David Holmes <david.hol...@oracle.com> wrote: > 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 >> >
