hg: jdk7/tl/jdk: 6977034: Thread.getState() very slow

Changeset: acce526a49a7 Author:mchung Date: 2010-12-08 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/acce526a49a7 6977034: Thread.getState() very slow Summary: Directly map the threadStatus value to Thread.State Reviewed-by: emcmanus, dholmes ! src/share/classes/java

Re: Review request for 6977034 Thread.getState() very slow

fferent states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ This is an improvement to map a Thread's threadStatus field to Thr

Re: Review request for 6977034 Thread.getState() very slow

pend on it, I will go for a > simpler approach (sequence of tests) and further tune its performance when > there is a use case requiring a perf improvement. > > New webrev: >    http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ > > Can you review this version? > > Thanks

Re: Review request for 6977034 Thread.getState() very slow

Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ This is an improvement to map a Thread's threadStatus field to Thread.State. The VM updates the Thread.threadStatus

Re: Review request for 6977034 Thread.getState() very slow

review this version? Thanks Mandy You could tweak the order of the tests based on what might be the relative frequency of the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at

Re: Review request for 6977034 Thread.getState() very slow

Fix for 6977034: Thread.getState() very slow Webrev at:    http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ This is an improvement to map a Thread's threadStatus field to Thread.State.  The VM updates the Thre

Re: Review request for 6977034 Thread.getState() very slow

java.net/~mchung/6977034/webrev.01/ Can you review this version? Thanks Mandy You could tweak the order of the tests based on what might be the relative frequency of the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 69770

Re: Review request for 6977034 Thread.getState() very slow

On 12/05/10 17:58, David Holmes wrote: Anyway, this was all premised on slow performance that Doug observed as part of ForkJoin mechanics. It would be good to hear back from him on how this updated approach performs. If the FJ code has changed such that this is no longer an issue then I would sug

Re: Review request for 6977034 Thread.getState() very slow

} } You could tweak the order of the tests based on what might be the relative frequency of the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.jav

Re: Review request for 6977034 Thread.getState() very slow

} You could tweak the order of the tests based on what might be the relative frequency of the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchun

Re: Review request for 6977034 Thread.getState() very slow

erent states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow

Re: Review request for 6977034 Thread.getState() very slow

n TERMINATED; } else { return NEW; } } You could tweak the order of the tests based on what might be the relative frequency of the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.get

Re: Review request for 6977034 Thread.getState() very slow

f the different states but it probably isn't worth it. Regards, Éamonn On 3/12/10 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at:    http://cr.openjdk.java.net/~mchung/6977034/webrev.00/

Re: Review request for 6977034 Thread.getState() very slow

On 12/03/2010 11:52 PM, Mandy Chung wrote: Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ Hi Mandy, you can use Integer.highestOneBit instead of the loop. Also, setMapElement should be a pure function, i.e without the side

Review request for 6977034 Thread.getState() very slow

Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ This is an improvement to map a Thread's threadStatus field to Thread.State. The VM updates the Thread.threadStatus field directly at state transition with the value as de

Re: Thread.getState() very slow

Doug, I ran into similar problems not too long ago. Dalvik uses a volatile field for the thread state. I wrote a sampling profiler for Dalvik. See SamplingProfiler.c

Re: Thread.getState() very slow

The problem is, when it comes to I/O, many operations are potentially blocking, but we don't know that a-priori. At best I think we could have a state that indicates it is executing an IO operation, but we can't know if it is actually blocking. David Jeremy Manson said the following on 08/14/

Re: Thread.getState() very slow

Second, FWIW. Our users are constantly baffled as to why all of their blocked-on-epoll threads are listed as RUNNABLE. Jeremy On Fri, Aug 13, 2010 at 10:18 AM, Martin Buchholz wrote: > As a related project, we could fix the JDK so that threads blocked in IO > operations would be much more likel

Re: Thread.getState() very slow

re to run into similar performance issues unless implementation is improved. Thanks for doing the experiment and the performance number which is great. I file 2 CRs: 6977034: Thread.getState() very slow 6977039: Extend Thread.State.BLOCKED to reflect blocking on I/O state Mandy

Re: Thread.getState() very slow

As a related project, we could fix the JDK so that threads blocked in IO operations would be much more likely to also report a thread state of BLOCKED. Martin On Fri, Aug 13, 2010 at 09:59, Doug Lea wrote: > Sorry for the long delay on this... > > > On 07/15/10 23:43, Mandy Chung wrote: > >> I

Re: Thread.getState() very slow

Sorry for the long delay on this... On 07/15/10 23:43, Mandy Chung wrote: I think making Thread.threadStatus a volatile field and using JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to Thread.State enum would be a good solution. It'd be great if Doug can do the experiment an

Re: Thread.getState() very slow

Hi Doug, David, I'm not aware of any CRs related to the performance of Thread.getState(). Like Alan said, the implementation hasn't been changed since JDK 5 release. Probably the existing usage of Thread.getState() is not as performance sensitive as the starvation detector requires and thus

Re: Thread.getState() very slow

Martin Buchholz wrote: : I don't know anything about the implementation of Thread.getState. Mandy? Mandy is on vacation at the moment so we might not hear from her for a few days. Looking through the history, the implementation doesn't seem to have changed since 2004. It does appear that

Re: Thread.getState() very slow

Martin Buchholz wrote: Some input from the original implementors would be useful (Martin? Mandy? I don't know anything about the implementation of Thread.getState. Mandy? I'm on vacation and will return on Thurs. We didn't do much optimization in the implementation. It has bee

Re: Thread.getState() very slow

On Sun, Jul 11, 2010 at 15:20, David Holmes wrote: > I thought this would be fairly simple but looking deeper into this it is a > lot more complicated than I thought. There is a three-level mapping from: > > OS/VM thread state -> VM ThreadStatus -> java.lang.ThreadState > > and it is a M:N:1 mapp

Re: Thread.getState() very slow

Hi Doug, Doug Lea said the following on 07/11/10 21:20: Also, while I'm at it, field Thread.threadStatus is suspiciously not declared volatile. Agreed - technically this should be a volatile field. In practice I think it only means that the window in which a stale value might be seen is slig

Re: Thread.getState() very slow

On 07/11/10 00:09, David Holmes wrote: Doug Lea said the following on 07/10/10 23:35: I've been trying out some improvements in ForkJoin that involve repeatedly scanning threads to check whether they are still in state Thread.State.RUNNABLE. My question is why you want to check for Runnable? I

Re: Thread.getState() very slow

Hi Doug, Doug Lea said the following on 07/10/10 23:35: I've been trying out some improvements in ForkJoin that involve repeatedly scanning threads to check whether they are still in state Thread.State.RUNNABLE. My question is why you want to check for Runnable? Is this a heuristic check to s

Thread.getState() very slow

I've been trying out some improvements in ForkJoin that involve repeatedly scanning threads to check whether they are still in state Thread.State.RUNNABLE. This is shockingly slow because getState() is implemented using a lookup table that requires a global lock (to ensure initialization) plus bo