Thread.getState() very slow

[David Holmes]

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/10 03:54:
> 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 <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
>> BLOCKED.
>>
>> Martin
>>
>> 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
>>>> Thread.State
>>>> enum would be a good solution.
>>>>
>>>>
>>>> It'd be great if Doug can do the experiment and evaluate the performance
>>>> impact.
>>>> 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.
>>>
>>> -Doug
>>>
>>