JDK-6200022 : JVMTI GetCurrentThreadCpuTime slow on Linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2004-11-24
  • Updated: 2017-05-16
  • Resolved: 2006-07-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b91Fixed
Related Reports
Relates :  
JDK-6491083 - ThreadMXBean.getCurrentThreadCpuTime() should use the posix clock implementation on Linux
Relates :  
JDK-6888526 - Linux getCurrentThreadCpuTime is drastically slower than Windows
Description
This bug is filed to remind us to re-examine the implementation of the GetCurrentThreadCpuTime function on Linux. Currently it opens /proc/<pid>/stat or /proc/<pid>/cpu (depending on the kernel version), and then closes the file. This makes the function impratical to use in a profiler. 

The not-yet-release 2.6.10 kernel appers to add posix compliant process clocks. This may mean that we can use pthread_getcpuclockid to read the clock for the current and other threads.
Here's the info on the new POSIX clock support:
   http://sources.redhat.com/ml/libc-alpha/2004-10/msg00117.html
Comments
SUGGESTED FIX Another suggested fix is in attachment: hs_ltime.Jun27.tar.gz Also, please, see the http://ccc.sfbay/6200022 .
27-06-2006
SUGGESTED FIX Please, see the webrev with suggested fix in attachments: hs_ltime.Jun13.tar.gz .
13-06-2006
EVALUATION The was a decision on the Serviceability/NetBeans meeting that we want to fix this bug in Mustang. It is because the NB profiling data can't be really useful without the fast time stamp feature. A preliminary estimate was that it is feasible to fix in one of the rc builds. So, the priority of the bug was raised to p2. For reference and details, please, see the link: http://www.unix.org/single_unix_specification/ The constant and functions of interest are: CLOCK_THREAD_CPUTIME_ID, clock_getres, clock_gettime, pthread_getcpuclockid
13-06-2006