Thread.getState() very slow
David.Holmes at oracle.com
Fri Aug 13 16:33:06 PDT 2010
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.
Jeremy Manson said the following on 08/14/10 03:54:
> Second, FWIW. Our users are constantly baffled as to why all of their
> blocked-on-epoll threads are listed as RUNNABLE.
> On Fri, Aug 13, 2010 at 10:18 AM, Martin Buchholz <martinrb at google.com> wrote:
>> 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
>> On Fri, Aug 13, 2010 at 09:59, Doug Lea <dl at cs.oswego.edu> wrote:
>>> 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
>>>> enum would be a good solution.
>>>> It'd be great if Doug can do the experiment and evaluate the performance
>>>> If you want me to prototype the jdk change, let me know and I should be
>>>> able to
>>>> make some time to do it next week.
>>> I did an equivalent experiment (of just directly accessing
>>> threadState via Unsafe.getIntVolatile and comparing it to
>>> cached values) and it was about 14X faster. So anything
>>> along these lines would be grat. That said, I decided not
>>> to try to rely on getState in the near term. (Among other
>>> reasons, it does not usually reflect IO blockage.) So this
>>> is off the critical path for now. But someday someone is sure
>>> to run into similar performance issues unless implementation
>>> is improved.
More information about the core-libs-dev