P5
A DESCRIPTION OF THE REQUEST :
The thread class doesn't provide any iinformation about the actual os level task id. In linux for example, the threads ids are all visible under /proc/self/tasks/*, but there is no way to assiciate those ids to a jvm native thread.
JUSTIFICATION :
The objective is to enable the use of the existing kernel monitoring data, especially the CPU usage ('jiffies'). Adding a Thread native method to return the os level task id would help making this association.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Typically, a thread can call for itself the libpthread pthread_self() and obtain a pthreadt structure which contains both the parent process id and the task id.
The pthread_self() must be calls from the thread itself and since developers cannot override the Thread.run() witnout implementing the thread themselves, it is usually impossible to figure out the task id of other threads.
Upon prior to starting its run() method, all threads could lookup its task id and save it in a 'Long' private variable that a simple public getter would expose.
It is understood that such API may be difficult (or irrelevant) to other platforms, but it higlights the need for platform-specific read-only metadata about threads. It is hardly a pure java API, but documenting the method as a platform-specific thread id, I think all jvm would either return null (if not implemented) or an opaque number of their choice (the most useful way on linux would be the 4 byte task id).
The jvm process id should also be saved in a similar way, but it is more appropriate to store it in a class like sun/misc.VM, or even java.lang.Runtime.
---------- BEGIN SOURCE ----------
There is really nothing more than having each thread call its own
libpthread pthread_self() and examine the pthreadt struct for the 'tid' field.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
If you are creating your own threads, and overriding run(), you may be able to call a native method to do the pthread_self() call, but there is no workaround to find the task id of system threads, GC threads, or other third party threads.
The thread class doesn't provide any iinformation about the actual os level task id. In linux for example, the threads ids are all visible under /proc/self/tasks/*, but there is no way to assiciate those ids to a jvm native thread.
JUSTIFICATION :
The objective is to enable the use of the existing kernel monitoring data, especially the CPU usage ('jiffies'). Adding a Thread native method to return the os level task id would help making this association.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Typically, a thread can call for itself the libpthread pthread_self() and obtain a pthreadt structure which contains both the parent process id and the task id.
The pthread_self() must be calls from the thread itself and since developers cannot override the Thread.run() witnout implementing the thread themselves, it is usually impossible to figure out the task id of other threads.
Upon prior to starting its run() method, all threads could lookup its task id and save it in a 'Long' private variable that a simple public getter would expose.
It is understood that such API may be difficult (or irrelevant) to other platforms, but it higlights the need for platform-specific read-only metadata about threads. It is hardly a pure java API, but documenting the method as a platform-specific thread id, I think all jvm would either return null (if not implemented) or an opaque number of their choice (the most useful way on linux would be the 4 byte task id).
The jvm process id should also be saved in a similar way, but it is more appropriate to store it in a class like sun/misc.VM, or even java.lang.Runtime.
---------- BEGIN SOURCE ----------
There is really nothing more than having each thread call its own
libpthread pthread_self() and examine the pthreadt struct for the 'tid' field.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
If you are creating your own threads, and overriding run(), you may be able to call a native method to do the pthread_self() call, but there is no workaround to find the task id of system threads, GC threads, or other third party threads.