Re: Thread Native ID Access

rrentThreadId() and getCurrentPlatformThreadId(). > > > > All this may seem somewhat overkill, but it’s no more so than how we > currently create ThreadInfo objects and the various ThreadCpu/UserTime > method definitions. > > > > Thanks, > > > > P

Re: Thread Native ID Access

, February 22, 2018 at 9:42 PM To: David Holmes Cc: "serviceability-dev@openjdk.java.net" , "loom-...@openjdk.java.net" , John Rose Subject: Re: Thread Native ID Access I think we're all pretty much agreed that fibers imply native tids can change. I think that, as long a

Re: Thread Native ID Access

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

Re: Thread Native ID Access

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

Re: Thread Native ID Access

On 23/02/2018 3:04 PM, John Rose wrote: On Feb 22, 2018, at 8:49 PM, David Holmes > 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

Re: Thread Native ID Access

On Feb 22, 2018, at 8:49 PM, David Holmes 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 n

Re: Thread Native ID Access

8 20:15 *An: *Bernd Eckenfels <mailto:e...@zusammenkunft.net> *Cc: *Alan Bateman <mailto:alan.bate...@oracle.com>; serviceability-dev@openjdk.java.net <mailto:serviceability-dev@openjdk.java.net>; loom-...@openjdk.java.net <mailto:loom-...@openjdk.java.net> *Betreff: *Re: T

Re: Thread Native ID Access

Eckenfels Cc: Alan Bateman; serviceability-dev@openjdk.java.net; loom-...@openjdk.java.net Betreff: Re: Thread Native ID Access Bernd, The thread ID needs to be unique, so that approach might actually cause problems with fibers, depending on their implementation. Jeremy On Thu, Feb 22, 2018 at

Re: Thread Native ID Access

: Re: Thread Native ID Access There isn't a pressing need.  I wrote this patch almost 5 years ago.  We can do what we've always done and keep the patch locally.  It's just more work for us to keep forward porting it, and loss of potential benefit to the community. I can certainly

Re: Thread Native ID Access

There isn't a pressing need. I wrote this patch almost 5 years ago. We can do what we've always done and keep the patch locally. It's just more work for us to keep forward porting it, and loss of potential benefit to the community. I can certainly understand not wanting this in the high-value r

Re: Thread Native ID Access

On 21/02/2018 22:40, Jeremy Manson wrote: Hey folks, I mentioned earlier in the thread about the ThreadInfo.from() bug that I found this because I was looking at fixing JDK-8154176, which proposes introducing native thread ids to Thread and ThreadInfo. https://bugs.openjdk.java.net/browse/JD

Re: Thread Native ID Access

Hi Jeremy, On Wed, Feb 21, 2018 at 11:40 PM, Jeremy Manson wrote: > Hey folks, > > I mentioned earlier in the thread about the ThreadInfo.from() bug that I > found this because I was looking at fixing JDK-8154176, which proposes > introducing native thread ids to Thread and ThreadInfo. > > https

Re: Thread Native ID Access

Hi Jeremy, I think "thread id" is too platform specific to be exposed in a core Java API like Thread - even as a non-descript String. Maybe through a platform specific MXBean API? For things like /proc//task/ is there a way to say in a way that means "current thread"? That may be a partial

Re: Thread Native ID Access

JDK 5 did very minimal for monitoring of native OS resources due to its scope and also its platform-dependent nature. I don't have a good advice how and where to expose them via Java SE API without further investigation. A couple of things come to mind: - Should native threads be exposed in Pro

Re: Thread Native ID Access

On Wed, Feb 21, 2018 at 2:40 PM, Jeremy Manson wrote: > > 1) Should the ID be a long? The Hotspot thread dump prints it out as > 0x%x, which is an unsigned hexadecimal integer. The type hiding behind it > is platform-dependent, though: a pid_t on Linux, an unsigned long on > Windows, a thread_t

Re: Thread Native ID Access

I'm not comfortable for ThreadInfo to expose the implementation details.  What should we specify w.r.t. Java Thread mapping to native thread which is platform dependent.  Also how does it relate to the future fibers [1]? Another alternative is for JDK specific diagnostic tools to do that mapp