Thread.getState() very slow

[David Holmes]

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 slightly longer. If threadStatus were exported directly it might be 
more of an issue, but as an internal detail of getState() it is not 
likely to be.

>> 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.

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 mapping

At least a startup you should be able to get the current thread's 
threadStatus and know that it represents RUNNABLE.

In addition I suspect the lazy initialization may be more necessary than 
I thought given the time at which this initialization might occur during 
the VM initialization sequence. I'd have to experiment (once I've 
remembered how to build regular SE Hotspot and the OpenJDK libs :) )

Some input from the original implementors would be useful (Martin? 
Mandy? ...)

That all said, you are the best person to evaluate the performance 
impact of any changes so it might be best if you are the one to do the 
initial experiments - using a simple volatile + DCL for the init as a 
first attempt perhaps.

David

> 
> -Doug
>