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
