RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5]

[Albert Mingkun Yang]

On Thu, 14 Aug 2025 11:27:10 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4953:
>> 
>>> 4951:       // to detach itself from the VM - which should result in ESRCH.
>>> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
>>> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);
>> 
>> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?
>> 
>> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.
>> 
>> The same goes for the other warnings below.
>
> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.

> ... it might happen from time to time without it being a very big deal?

My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276473605