From kevinw at openjdk.org  Thu May  1 10:09:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 10:09:44 GMT
Subject: jmx-dev RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows [v2]
In-Reply-To: <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
Message-ID: <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>

On Wed, 30 Apr 2025 21:20:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I would simplify to 
>> 
>>  for (int i = 0; i < TEST_COUNT; i++) {
>>             double load = mbean.getProcessCpuLoad();
>>             if (load == -1.0 && Platform.isWindows()) {
>>                 // Some Windows 2019 systems can return -1 for the first few reads.
>>                 // Remember a -1 in case it never gets better.
>>                 // Some Windows systems can return -1 occasionally, at any time.
>>                 // Will fail if we never see good values.
>>                
>>             } else if (load < 0.0 || load > 1.0) {
>>                 throw new RuntimeException("getProcessCpuLoad() returns " + load
>>                           + " which is not in the [0.0,1.0] interval");
>>             } else { 
>>                // we got at least one load from 0.0 to 1.0, that's good to pass on Wiindows
>>                 good++;
>>           }
>>             try {
>>                 Thread.sleep(200);
>> 
>>             }
>>         }
>> 
>>     
>>         if (good == 0 && Platform.isWindows()) {
>>             // Never get any good results on Windows 2019
>>             throw throw new RuntimeException("getProcessCpuLoad() returns  always -1.0 on Windows in 10 attempts. ");
>>         }
>>     }
>> 
>> does it makes a sense?
>
> Thanks Leonid, yes we could do it like that.  There have to be a load of ways we could arrange this.  Yes, it could be a little simpler that what we have now, although it's not _that_ complicated now...

I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
I also like keeping the existing Exception wording, there isn't a real need to change it.
It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
On balance would you be OK if we leave as it stands?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070119265

From lmesnik at openjdk.org  Thu May  1 15:52:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 May 2025 15:52:46 GMT
Subject: jmx-dev RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows [v2]
In-Reply-To: <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
Message-ID: <dOQbLsuhj3ixdEi7GeofDBkboI1XlsP6voEk3MifiH4=.d5b27640-0b61-4a52-b629-01476d678443@github.com>

On Wed, 30 Apr 2025 18:42:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
>> 
>> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
>> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to check ex at end,  when failing

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24961#pullrequestreview-2810079167

From kevinw at openjdk.org  Thu May  1 16:08:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 16:08:50 GMT
Subject: jmx-dev RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows [v2]
In-Reply-To: <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <M8Idw5FPha6VMgLzydvgGH5qo2ZOkQ10TNZbtpD5NII=.1784ff8f-e3c1-48e1-aa75-df4bb62c9719@github.com>
Message-ID: <oRudO4wFOK863D4-G3xXTg_DKyyvrJWmqHshxeviggM=.cc668df4-34db-4700-a2b9-57109a096162@github.com>

On Wed, 30 Apr 2025 18:42:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
>> 
>> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
>> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to check ex at end,  when failing

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24961#issuecomment-2845146716

From kevinw at openjdk.org  Thu May  1 16:08:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 16:08:50 GMT
Subject: jmx-dev Integrated: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows
In-Reply-To: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
Message-ID: <s_Uk3YYkvanCOOqD-ImjwLZjkaBXoaedWZYS8V3l1I8=.67ebdcb6-5292-4954-a8eb-28e2d417d089@github.com>

On Wed, 30 Apr 2025 11:13:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is hard to reproduce, and at first I'd only seen -1 returned on the first calls to mbean.getProcessCpuLoad().
> But eventually I observed a -1 at any time, including in middle of the iterations, or on the last iteration which makes the current test fail.
> 
> Should fail on Windows only if we only ever see -1 returned from getProcessCpuLoad().
> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding "exclusiveAccess.dirs=." did not fix this.)

This pull request has now been integrated.

Changeset: 09cae5fd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09cae5fd8f228a8826e4de7aa43fe5365549c00c
Stats:     35 lines in 2 files changed: 5 ins; 24 del; 6 mod

8354407: Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails on Windows

Reviewed-by: cjplummer, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/24961

From lmesnik at openjdk.org  Thu May  1 15:52:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 May 2025 15:52:48 GMT
Subject: jmx-dev RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows [v2]
In-Reply-To: <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
 <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
Message-ID: <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>

On Thu, 1 May 2025 10:07:04 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Thanks Leonid, yes we could do it like that.  There have to be a load of ways we could arrange this.  Yes, it could be a little simpler that what we have now, although it's not _that_ complicated now...
>
> I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
> I also like keeping the existing Exception wording, there isn't a real need to change it.
> It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
> On balance would you be OK if we leave as it stands?

sure, let left it as it is. 
Let return to this once 2019 is going to be EOL and remove all this stuff:
Looks good for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070435139

From kevinw at openjdk.org  Thu May  1 15:55:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 May 2025 15:55:44 GMT
Subject: jmx-dev RFR: 8354407: Test
 com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java still fails
 on Windows [v2]
In-Reply-To: <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>
References: <72oWIJeRPYV1kgfqEXQpSnzzgEhKhIOGldcnauQH4pI=.e6b4ad7a-4430-41a2-bac3-42ebbfa5073c@github.com>
 <7ILfLmjYPgmU5h5c4J_tZIYppwR-EY534g47X4ZOGb8=.bb79b3b7-376f-414d-af1f-602202aaa8c5@github.com>
 <hkMZgP7W5-CsQcU9sVu2y9ccegLDywZZvzIE_Fc1xCI=.83916c80-3358-4bbe-9f9e-fb354feacc4f@github.com>
 <i_POOAfgtMKXcynZ7JOhzFE3g6zRFpcZTYPeliwnb0k=.ddca030c-603e-4c8d-888d-113892bd33f2@github.com>
 <9EsAzO09Flx3F1L9XQ8pvk3vcpmvl5CDtlCdqT1hGL0=.e0ad1482-11cd-4527-b8a8-bb883796fdc0@github.com>
 <br2NXvoSjr62Rm-seeds7f03Cia0FSYSzhV2c87qQoU=.9b3179fa-112a-4ace-a072-a61760767418@github.com>
 <zQ5iEYnBjF4jLt_P3LSIR5dyByPJ7QPdgokdfnJ3jfU=.c27f78df-8e3f-46f6-8eaa-c7935a027713@github.com>
Message-ID: <lrPifNN_P8b4g_6VKhIMgy6yOA_zaycL86dVT3hz7Uo=.a3959245-3a52-4119-ab26-73a9d0bfe90d@github.com>

On Thu, 1 May 2025 15:49:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> I do like having the Exception created at the point where we recognise there's a problem.  While the message could hard-code in the -1 in the Windows case, it must be also good to use the same expression to build the message, right next to each other.
>> I also like keeping the existing Exception wording, there isn't a real need to change it.
>> It's still a tiny little test routine and on future failure on Windows, it should be clear that we didn't receive any good values.
>> On balance would you be OK if we leave as it stands?
>
> sure, let left it as it is. 
> Let return to this once 2019 is going to be EOL and remove all this stuff:
> Looks good for me.

Thanks Leonid!

Eventually there were a few failures on other Windows versions, so I removed the specific mention of Windows 2019, although it was most common.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2070440202

From kevinw at openjdk.org  Tue May  6 11:13:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 6 May 2025 11:13:06 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad
 and getProcessCpuLoad are stale after 24.8 days (Windows)
Message-ID: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>

OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
"maximum clock function return value of 2147483.647 seconds, or about 24.8 days"

The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.

The example code also notes that _ftime is deprecated, so _ftime_s is used here.

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

Commit messages:
 - 8351359: OperatingSystemMXBean stops reporting cpuLoad and processCpuLoad after 24.8 days

Changes: https://git.openjdk.org/jdk/pull/25062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351359
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25062/head:pull/25062

PR: https://git.openjdk.org/jdk/pull/25062

From amenkov at openjdk.org  Wed May  7 00:41:18 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 00:41:18 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <eEgCmGXb70ETbxYs9kPVDcB8DXLLXxxq2u2YywU49uI=.861055ef-d84b-4ba1-98ea-ce13bd24db29@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

I'm not sure use current system time here is a good idea. system time may be updated (manually or automatically) and this will break the logic (if you change system time 1 hour back, there will be no updates for the next hour..)
May be use `GetTickCount`? it's low-res (10ms IIRC), but it's ok for the case.
It overflows in 50 days, but there is no problem is you use DWORD arithmetic. Or newer `GetTickCount64` (available from Vista) may be used instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2856684373

From kevinw at openjdk.org  Wed May  7 11:25:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 May 2025 11:25:32 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Use GetTickCount64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25062/files
  - new: https://git.openjdk.org/jdk/pull/25062/files/3dd8362f..c7861219

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25062&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25062&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25062/head:pull/25062

PR: https://git.openjdk.org/jdk/pull/25062

From kevinw at openjdk.org  Wed May  7 11:25:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 May 2025 11:25:32 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <ckG6ttuudtK0ta4M-Zzjzg4kcoF1IITCtznl5xHv7dE=.e1b99183-538a-41d8-830a-3a4d2427d0de@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

Thanks Alex -
Yes, good point, and luckily it isn't that bad.  GetTickCount64 does look like a good choice, I'm updating this.  _ftime_s() works fine in practice but GetTickCount64 seems like a better choice.

Testing existing behaviour using clock(), using _ftime_s(), and using GetTickCount64(): setting the clock back breaks one sample, we return -1, and keep returning that for one sampling "window", then it's fixed.  That's a reasonable disruption when the system time is changed, and is how it's always been.

With ftime_s() I suppose it's the negative time difference being treated as an unsigned uint64_t, it's a very big number, so the behaviour is the same as other methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2858199438

From amenkov at openjdk.org  Wed May  7 18:30:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 May 2025 18:30:56 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <nmybMCSqbQ7Qjq5IOzCDRBKkKPUwpUmPaN_dbGHFs1E=.e81229ca-07f1-44cc-9477-e5c57d01e0be@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> The example code also notes that _ftime is deprecated, so _ftime_s is used here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25062#pullrequestreview-2822755498

From sspitsyn at openjdk.org  Wed May  7 22:24:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 May 2025 22:24:51 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <z_AlzI-m_lDAxanpgO0E8_d8fSId3UWapHN5ZCFA8l8=.26dc81d2-750b-48db-a94f-8c7b4554c744@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> Update: GetTickCount64() is a better alternative.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25062#pullrequestreview-2823339785

From kevinw at openjdk.org  Thu May  8 13:20:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 13:20:57 GMT
Subject: jmx-dev RFR: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows) [v2]
In-Reply-To: <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
 <2aXRAvEELNXYKCJLO5YyvN9hLbfuoJIIPks3EzWQ5JU=.16a95a01-6d1b-49e9-8e66-a4d2f454e810@github.com>
Message-ID: <FXdPsgBz8d6mE-whWjTo0N75W_-f9fs0x6KrDpjgRNk=.768e7183-50e3-4e21-9fd6-4e21b88eeb2e@github.com>

On Wed, 7 May 2025 11:25:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
>> 
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
>> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
>> 
>> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
>> 
>> Update: GetTickCount64() is a better alternative.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use GetTickCount64

Thanks Alex, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2863032652

From kevinw at openjdk.org  Thu May  8 13:20:58 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 13:20:58 GMT
Subject: jmx-dev Integrated: 8351359: OperatingSystemMXBean: values from
 getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)
In-Reply-To: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
References: <_h5qByBYiYeRh1oAFU3_EPQkHbuQb2ZKW4HEnk8nWlc=.0bd67d92-8148-40b7-a157-25ca1d9e2720@github.com>
Message-ID: <90Y3fwOBgHupYnvL-f7UhsmcvUmLgEpi1Lyf3sjwGIs=.2fde9f7c-9ba7-4f79-8308-225808c30c11@github.com>

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> Update: GetTickCount64() is a better alternative.

This pull request has now been integrated.

Changeset: 900b3ff7
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/900b3ff7ee933520efe2438fb7c841a4e6a93d17
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8351359: OperatingSystemMXBean: values from getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/25062