JDK-4939080 : JVMTI spec: jvmtiThreadStatus should match java.lang.management.ThreadState
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2003-10-16
  • Updated: 2017-05-16
  • Resolved: 2004-02-06
Related Reports
Duplicate :  
JDK-4980307 - JVMTI Spec: thread state query should allow for future expansion
Duplicate :  
JDK-4950589 - JVMTI spec: thread status constants - normalize names, renumber, add park
Relates :  
JDK-4937022 - JVMTI spec: need JVMTI_THREAD_STATUS_IO_WAIT
Relates :  
JDK-4639363 - Java Platform Profiling Architecture (JSR-163)
Description
1) Names should match (ThreadState has better names, so JVMTI should change):

	JVMTI_THREAD_STATUS_ZOMBIE   ==> JVMTI_THREAD_STATUS_TERMINATED
	JVMTI_THREAD_STATUS_MONITOR  ==> JVMTI_THREAD_STATUS_BLOCKED

   Old names should remain additionally to allow a smooth transition but
   must be removed before release.

2) Not all platforms can provide JVMTI_THREAD_STATUS_IO_WAIT, so it should
   be conditional on a capability: can_get_io_wait_status

3) The constants should be renumbered so as to be in a reasonable order,
   to be non-negative, to allow for the above, and to be unique.
Comments
EVALUATION A new set of thread states, and a new function to get the state of a thread (GetThreadState) was introduced via 4980307 (b38). The new thread state is extensible and so can cater for states that are only implementable in some VM implementations. As there's no further work to for this bug I'm closing it as a duplicate of 4980307 -- ie: the issue noted in the description is addressed as of b38.
11-06-2004