Review request for 6977034 Thread.getState() very slow

[Rémi Forax]

On 12/03/2010 11:52 PM, Mandy Chung wrote:
> Fix for 6977034: Thread.getState() very slow
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/

Hi Mandy,
you can use Integer.highestOneBit instead of the loop.

Also, setMapElement should be a pure function, i.e without the side 
effect on array.
In that case,

setMapElement(map, JVMTI_THREAD_STATE_TERMINATED,               TERMINATED);

can be transformed to

map[JVMTI_THREAD_STATE_TERMINATED] = highestJVMTIStateBit(TERMINATED);

so the access to the array element is not far from the creation
of the array so the VM can remove array bound checks even if
highestJVMTIStateBit is not inlined.

>
> This is an improvement to map a Thread's threadStatus field to 
> Thread.State.  The VM updates the Thread.threadStatus field directly 
> at state transition with the value as defined in JVM TI [1].  The 
> java.lang.Thread.getState() implementation can directly access the 
> threadStatus value and do a direct lookup from an array of 
> Thread.State.  The threadStatus value is a bit vector and we would 
> have to create an array of a minimum of 1061 (0x425) elements to do 
> direct mapping.   I took the approach to use the first highest order 
> bit set to 1 in the masked threadStatus value as the index to the 
> Thread.State element and only caches 32 elements (could be fewer).  I 
> wrote a micro-benchmark measuring the Thread.getState of a thread in 
> different state that shows 1.7X to 6X speedup (see below).  There is 
> possibly some issue with my micro-benchmark that I didn't observe the 
> 14X speed up as Doug did in his experiment.  However, I'd like to get 
> this reviewed and pushed to the repository so that anyone can do more 
> experiment on the performance measurement.
>
> Thanks
> Mandy
> P.S. The discussion on this thread can be found at [2] [3].
>
> [1] 
> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState
> [2] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html
>
>
> 	JDK 7 b120 (in ms)	With fix (in ms)	Speed up
> main		46465	        22772			2.04
> NEW		50676		29921			1.69
> RUNNABLE	42202		14690			2.87
> BLOCKED		72773		12296			5.92
> WAITING		48811		13041			3.74
> TIMED_WAITING	45737		12849			3.56
> TERMINATED	40314		16376			2.46
>

Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20101204/c9934fc1/attachment.html>