Thread.getState() very slow

[Doug Lea]

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? Is this a heuristic check to
> see that the thread is not blocked? Only basic monitor related blocking will
> update the thread state. Is that enough for what you want?

It's one part of a starvation detector for which it is OK
to be wrong conservatively.
For some of the motivation, see the concurrency-interest post
http://cs.oswego.edu/pipermail/concurrency-interest/2010-July/007251.html

>
> That said the set of states is small enough that two arrays could easily be used
> instead of the maps.

Or, depending on the range of values of Thread.threadStatus, bit
maps might work, and would avoid traversal.

Also, while I'm at it, field Thread.threadStatus is suspiciously not
declared volatile.

>
>> Or alternatively, is there a faster way to check that
>> internal field Thread.threadStatus has the value mapping
>> to RUNNABLE?
>
> Can you use Unsafe to grab the field directly, or would the reflection make it
> too slow?
>

That's what I'm currently doing as a sleazy workaround.
The sleaziness is not the Unsafe, which is basically fine
since this is planned for JDK code, but having to guess at startup
that the first value I get must be the one associated with RUNNABLE.

-Doug