Hey David, Thanks for the offer of sponsorship. My goal here is really to make the log output on Linux usable. I want to be able to map the log output back to an actual thread. I don't think it really matters to users if the API consistently means "kernel thread ID" or "threading API thread ID", as long as they can figure out what the output means.
Since what I am doing (in effect) to accomplish my goal is to ensure that the API returns the same value as osthread()->thread_id() does for the current thread, I could just... do precisely that. os::current_thread_id could just return osthread()->thread_id() for the current thread. I don't have easy access to anything for testing other than Linux, though, so whether it worked (or even compiled) on the other platforms would be a bit of a guess (per the last time we did this dance). Seem reasonable? Jeremy On Wed, Jul 22, 2015 at 7:08 PM, David Holmes <david.hol...@oracle.com> wrote: > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > >> Based on the feedback, this seems to be a good idea, approximately. >> Coleen would have sponsored, but she's going on vacation. Anyone else >> feel like sponsoring? >> > > Hold up a minute! :) There are different notions of "native thread id" > that exist. First we have the "user level thread id" - this is what is > reported by pthread_self in POSIX and thr_self in UI. Then we also have the > OS specific "thread" id, also referred to as a LWP or "kernel scheduling > entity" or "kernel thread" - the id for this is what gettid() maps back to > on Linux. This distinction may not exist on all platforms. > > Unfortunately os::current_thread_id does not define which of these it > represents: > > // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit > static intx current_thread_id(); > > and so on some platforms it returns the "user thread id" (eg > pthread_self()), and on some it returns the same as gettid (ie OSX - but I > don't know if the mach thread id is truly a "LWP" id ?). > > Also note that on some platforms the osThread stores the id of the > "user-level thread" and on some the "kernel thread". Hence another source > of confusion. :( > > So if you want to enforce that os::current_thread_id() represents the > "kernel thread" then that should be applied consistently across all > platforms**, and for platforms for which there is a change to make you have > to ensure the usage of os::current_thread_id() is not semantically altered > by the change. > > ** Of course a platform may only have a single notion of "thread" > > I'm happy to sponsor such a proposal. And don't worry about maintaining > compatibility with archaic Linux versions for JDK9 (less cleanup to do > later). > > Thanks, > David > > Jeremy >> >> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson <jeremyman...@google.com >> <mailto:jeremyman...@google.com>> wrote: >> >> Hey folks, >> >> os::current_thread_id on Linux now maps to pthread_self. The >> problem with pthread_self is that it only makes sense in the context >> of the running process. When it is written out to the log (as it is >> in several places), there really isn't a way (AFAICT) for the user >> to map it back to anything useful. >> >> As it happens, that value is mostly used to write to the log. The >> places where it doesn't do so don't seem to need to use pthread_self >> for any particular reason. >> >> Meanwhile, the SIGQUIT stack dump >> uses java_thread->osthread()->thread_id() as the nid. On Linux, >> that maps back to os::Linux::gettid(), whish is also what gets >> exposed in /proc. That makes it much easier to see what threads >> might be doing the log write. >> >> Would it be okay to change os::current_thread_id to point >> to os::Linux::gettid()? That way, it can be mapped back to the >> output of a SIGQUIT dump. >> >> The downside of gettid() is that it is only available on >> Linux>2.4.11, but that dates from 2001. If we really still want to >> support it, we could check for that. >> >> Thoughts? >> >> Jeremy >> >> >>
