-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b91
-
generic
-
linux
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
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
- relates to
-
JDK-6888526 Linux getCurrentThreadCpuTime is drastically slower than Windows
-
- Closed
-
-
JDK-8338947 Deprecate the UseLinuxPosixThreadCPUClocks flag and remove it in a future release
-
- Resolved
-
-
JDK-6491083 ThreadMXBean.getCurrentThreadCpuTime() should use the posix clock implementation on Linux
-
- Resolved
-