Hi Doug,
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?
Not to mention the inherent race in doing the check.
This is shockingly slow because getState() is implemented
using a lookup table that requires a global lock
(to ensure initialization) plus boxing to do the lookup.
We can easily fix the lock issue with a DCL check and making the main
map volatile. (Or simply skip lazy initialization as I would think this
is always used!)
Is the boxing really an issue? Due to the values used there should not
be any object creation - right?
That said the set of states is small enough that two arrays could easily
be used instead of the maps.
Practically any other implementation would be faster.
For example, simply scanning the small static array of
sun.misc.VM.getThreadStateValues. And surely there are
better ways.
Is anyone looking into this?
I don't see any CRs related to this so I would not expect anyone to be
looking at it ... until now of course :)
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?
Cheers,
David
If not, I might try contributing a patch.
-Doug
