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 <[email protected]> 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 <[email protected]> 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
