RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v5]

[David Holmes]

On Mon, 1 Dec 2025 16:09:02 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 §3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
>> 
>> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
>> 
>> Before patch:
>> 
>> Benchmark                  Mode      Cnt  Score    Error  Units
>> CPUTime.execute          sample  7506555  0.008 ±  0.001  ms/op
>> CPUTime.execute:p0.00    sample           0.008           ms/op
>> CPUTime.execute:p0.50    sample           0.008           ms/op
>> CPUTime.execute:p0.90    sample           0.008           ms/op
>> CPUTime.execute:p0.95    sample           0.008           ms/op
>> CPUTime.execute:p0.99    sample           0.012           ms/op
>> CPUTime.execute:p0.999   sample           0.015           ms/op
>> CPUTime.execute:p0.9999  sample           0.021           ms/op
>> CPUTime.execute:p1.00    sample           1.030           ms/op
>> 
>> 
>> After patch:
>> 
>> Benchmark                  Mode      Cnt   Score    Error  Units
>> CPUTime.execute          sample  8984189  ≈ 10⁻³           ms/op
>> CPUTime.execute:p0.00    sample           ≈ 10⁻³           ms/op
>> CPUTime.execute:p0.50    sample           ≈ 10⁻³           ms/op
>> CPUTime.execute:p0.90    sample           ≈ 10⁻³           ms/op
>> CPUTime.execute:p0.95    sample           ≈ 10⁻³           ms/op
>> CPUTime.execute:p0.99    sample            0.001           ms/op
>> CPUTime.execute:p0.999   sample            0.001           ms/op
>> CPUTime.execute:p0.9999  sample            0.006           ms/op
>> CPUTime.execute:p1.00    sample            0.054           ms/op
>> 
>> 
>> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add fixes from @cl4es review comments

src/hotspot/os/linux/os_linux.cpp line 4966:

> 4964: // for the Linux kernel defaults to construct a clockid with 010 (CPUCLOCK_SCHED)
> 4965: // set, which return system+user time, which is what the POSIX standard mandates, see
> 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 §3.90.

I think the bit encoding could be made somewhat clearer.

// Since kernel v2.6.12 the Linux ABI has had support for encoding the clock types in
// the last three bits. Bit 2 indicates whether a cpu clock refers to a thread or a process.
// Bits 1 and 0 give the type: PROF=0, VIRT=1, SCHED=2, or FD=3. 
// The clock CPUCLOCK_VIRT (0b001) reports the thread's consumed user time. 
// POSIX compliant implementations of pthread_getcpuclockid return the clock CPUCLOCK_SCHED
// (0b010) which reports the thread's consumed system+user time (as mandated by the POSIX
// standard POSIX.1-2024/IEEE Std 1003.1-2024 §3.90)

src/hotspot/os/linux/os_linux.cpp line 4967:

> 4965: // set, which return system+user time, which is what the POSIX standard mandates, see
> 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 §3.90.
> 4967: static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) {

Suggestion:

// The out parameter `success` is required to be initialized to `true`.
static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) {
  assert(success != nullptr && *success, "incorrect initialization");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580342601
PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580349403