From dholmes at openjdk.org  Sun Mar  2 20:56:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 2 Mar 2025 20:56:55 GMT
Subject: jmx-dev RFR: 8350818: Improve OperatingSystemMXBean cpu load
 tests to not accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <OeuwF4Wil3172tkQNjVJSgkLebYp2zKr-Yr0Ka84PU8=.25521798-6226-4c16-adf3-6d7cdff74f27@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

@lmesnik this test is now failing a lot in our CI! I will file a new bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/23833#issuecomment-2692902822

From dholmes at openjdk.org  Sun Mar  2 21:02:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 2 Mar 2025 21:02:01 GMT
Subject: jmx-dev RFR: 8350818: Improve OperatingSystemMXBean cpu load
 tests to not accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <SX8mC2FEqOGgoqFzsVWE8uUUlwLiny61mvDmPgafiIc=.4d0a020a-dc70-49a9-b33e-b1a6c52be301@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

I see [JDK-8351002](https://bugs.openjdk.org/browse/JDK-8351002) was already filed

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

PR Comment: https://git.openjdk.org/jdk/pull/23833#issuecomment-2692905065

From kevinw at openjdk.org  Mon Mar  3 17:17:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 17:17:30 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size calculation
 for OperatingSystemMXBean
Message-ID: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>

Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).

This change moves to snprintf again, but the counter names are not truncated.

snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

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

Commit messages:
 - 8350939: Revisit Windows PDH buffer size calculation for OperatingSystemMXBean

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

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

From kevinw at openjdk.org  Mon Mar  3 17:17:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 17:17:30 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

In makeFullCounterPath():

We calculate a size (length of the counter in characters), which might be '\Process(java#0)% Processor Time', 33 chars.
That size does not include the null terminator.
We malloc a buffer of (size+1).
Then we use the original size in the _snprintf.

This has worked for years.  But snprintf is slightly different.

snprintf behaviour:

https://en.cppreference.com/w/c/io/fprintf (including snprintf)
"At most bufsz - 1 characters are written. The resulting character string will be terminated with a null character"

That seems enough to say we have a problem.  Although its wording could be clearer on whether "bufsz-1 characters" includes the null.
	 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170

"snprintf always stores a terminating NULL character, truncating the output if necessary."

"The difference is that if you run out of buffer, snprintf null-terminates the end of the buffer and returns the number of characters that would have been required whereas _snprintf doesn't null-terminate the buffer and returns -1. Also, snprintf() includes one more character in the output because it doesn't null-terminate the buffer."

(the last sentence quoted there seems to contradict the first)

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

Did we run out of buffer? 
snprintf called with a 33 char string and a buf len of 33, it won't have room for the null (there is room in the malloc'd buffer, but the len passed to snprintf does not include it).  So it truncates and writes a null within the bounds it knows about.

snprintf needs the null to fit inside the buffer length given.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2695039462

From dholmes at openjdk.org  Tue Mar  4 06:42:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:42:51 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
Message-ID: <L5t_VF88IOIcKH4ddvExlZTaOonfY4pjcGDHI1zCAH8=.51b89608-1790-4cb2-a87b-0aad737b445a@github.com>

On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (the last sentence quoted there seems to contradict the first)

I think it is a typo and meant to say `_snprintf` not `snprintf`. I added feedback to the MS page.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2696371535

From dholmes at openjdk.org  Tue Mar  4 06:47:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:47:52 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Fix looks good. Thanks.

src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:

> 294: /* PDH format patterns, and lengths of their constant component. */
> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;

Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2656144269
PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1978719502

From kevinw at openjdk.org  Tue Mar  4 08:17:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 4 Mar 2025 08:17:53 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
Message-ID: <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>

On Tue, 4 Mar 2025 06:42:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
>> 
>> This change moves to snprintf again, but the counter names are not truncated.
>> 
>> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).
>
> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:
> 
>> 294: /* PDH format patterns, and lengths of their constant component. */
>> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
>> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;
> 
> Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??

Yes was trying to clarify that with the comment: the "constant component", the number of fixed characters.  So allocation size is e.g. OBJECT_COUNTER_FMT_LEN (==2) to account for the two backslashes in that format, plus the lengths of the two strings, plus the terminator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1978858171

From dholmes at openjdk.org  Tue Mar  4 11:50:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 11:50:54 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
 <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>
Message-ID: <uz2jUM_w0vivU16ycywVvc-Qjien1shWZLXjUC4o2Fg=.24ff5b77-98b0-4ea9-ba57-3698be5765c7@github.com>

On Tue, 4 Mar 2025 08:14:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:
>> 
>>> 294: /* PDH format patterns, and lengths of their constant component. */
>>> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
>>> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;
>> 
>> Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??
>
> Yes was trying to clarify that with the comment: the "constant component", the number of fixed characters.  So allocation size is e.g. OBJECT_COUNTER_FMT_LEN (==2) to account for the two backslashes in that format.  The lengths of the two strings, plus the terminator, are added in the method that constructs the counter path..

Ah! Makes sense now. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1979271076

From lmesnik at openjdk.org  Wed Mar  5 19:28:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 5 Mar 2025 19:28:52 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

I assume you tested the changes, even tests are problemlisted now.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2662279073

From kevinw at openjdk.org  Wed Mar  5 19:57:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 5 Mar 2025 19:57:57 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>
Message-ID: <23Nz2gLPAuq6m1mGl0CJIhuUW6WQZHvNrYT8pZ4sSnE=.2d28b6df-aa08-4ed5-8214-ebccadd344aa@github.com>

On Wed, 5 Mar 2025 19:26:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I assume you tested the changes, even tests are problemlisted now.

Thanks Leonid, yes tested manually and with the tests.  Will look at the tests and again and see if we can see why they had some failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2701927915

From sspitsyn at openjdk.org  Wed Mar  5 23:36:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 5 Mar 2025 23:36:52 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <L6hV533uGWb4p3xAm0zkmB8H4UAVvkHZ1pFs61tnAF4=.4a7bccf5-b997-44d1-be31-1db5e99b38bf@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2662733039

From kevinw at openjdk.org  Thu Mar  6 12:30:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 12:30:06 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <puSf7JAHZOAA_J5J8Smo-v4Kzjzr4BetnhKm46VUe6A=.48a8f133-f0c5-4943-bb05-84f035d91a3d@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Thanks for reviews.
Reran with edited problemlist to run relevant tests, all good.
Hope we can clear problemlist in near future!...

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703704150

From kevinw at openjdk.org  Thu Mar  6 12:30:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 12:30:07 GMT
Subject: jmx-dev Integrated: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <qI6LWYY5HGJjqxvj4nncCLYzZ1bsTgoS3y1jJY0EdzA=.ff994b6d-f336-4698-8683-e2750c81b33b@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

This pull request has now been integrated.

Changeset: 8f8a879d
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f8a879de03add68e385f2610863d3b4ddd86df7
Stats:     41 lines in 1 file changed: 0 ins; 5 del; 36 mod

8350939: Revisit Windows PDH buffer size calculation for OperatingSystemMXBean

Reviewed-by: dholmes, lmesnik, sspitsyn

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

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

From jpai at openjdk.org  Thu Mar  6 13:28:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 13:28:12 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
Message-ID: <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>

On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> We calculate a size (length of the counter in characters), which might be '\Process(java#0)% Processor Time', 33 chars.

Isn't that 32 characters?

I understood the rest of the explanation in this PR and the change sounds reasonable to me. It's just this character count that I'm unsure about. Is that a typo?

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703849110

From kevinw at openjdk.org  Thu Mar  6 14:20:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 14:20:06 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
 <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
Message-ID: <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>

On Thu, 6 Mar 2025 13:25:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Isn't that 32 characters?

Yes thanks well spotted.  Just to clarify, looks like I dropped a backslash while making that note, the counter would look like `'\Process(java#0)% Processor Time' `

8-)

(Correction, I didn't drop a backslash, it's being formatted here in github...)

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703969446

From jpai at openjdk.org  Thu Mar  6 14:20:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 14:20:06 GMT
Subject: jmx-dev RFR: 8350939: Revisit Windows PDH buffer size
 calculation for OperatingSystemMXBean
In-Reply-To: <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
 <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
 <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>
Message-ID: <1GnM46WdduLt66D1g5nwQyvgyPgEHQHt6BwNoHx3ntA=.129cd53e-c11b-4ccd-8ed5-b07d92535c64@github.com>

On Thu, 6 Mar 2025 14:13:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > Isn't that 32 characters?
> 
> Yes thanks well spotted. Just to clarify, looks like I dropped a backslash while making that note, the counter would look like `'\Process(java#0)% Processor Time' `
> 
> 8-)
> 
> (Correction, I didn't drop a backslash, it's being formatted here in github...)

Thank you Kevin for clarifying. It all looks good and matches what you noted in your description.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703982118

From kevinw at openjdk.org  Mon Mar 24 11:54:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 11:54:49 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently
Message-ID: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>

These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.

They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.

GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.

The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

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

Commit messages:
 - whitespace
 - problemlist
 - Merge remote-tracking branch 'upstream/master' into 8351002_OSMXBean_CPU_Tests
 - 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently

Changes: https://git.openjdk.org/jdk/pull/24186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351002
  Stats: 59 lines in 4 files changed: 44 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24186/head:pull/24186

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

From aturbanov at openjdk.org  Mon Mar 24 14:56:10 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 24 Mar 2025 14:56:10 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <o4T4iQjlebKVYbC57dgxjCH3b0XLiiv8gpXWuT6KnYY=.d8ccc711-ac70-4d02-aaa0-90e8d8f11076@github.com>

On Mon, 24 Mar 2025 10:13:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 43:

> 41:         double load;
> 42: 
> 43:         for(int i = 0; i < 10; i++) {

Suggestion:

        for (int i = 0; i < 10; i++) {

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 43:

> 41:         double load;
> 42: 
> 43:         for(int i = 0; i < 10; i++) {

Suggestion:

        for (int i = 0; i < 10; i++) {

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 49:

> 47:                 // Remember a -1 in case it never gets better.
> 48:                 ex = new RuntimeException("getSystemCpuLoad() returns " + load
> 49:                          +  " which is not in the [0.0,1.0] interval");

Suggestion:

                         + " which is not in the [0.0,1.0] interval");

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 53:

> 51:             } else if (load < 0.0 || load > 1.0) {
> 52:                 throw new RuntimeException("getSystemCpuLoad() returns " + load
> 53:                            +  " which is not in the [0.0,1.0] interval");

Suggestion:

                           + " which is not in the [0.0,1.0] interval");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010344429
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010344971
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010345618
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010346257

From kevinw at openjdk.org  Mon Mar 24 15:08:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 15:08:01 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v2]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/21ebab5b..2cfd63ce

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

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

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

From lmesnik at openjdk.org  Mon Mar 24 20:15:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Mar 2025 20:15:14 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v2]
In-Reply-To: <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
Message-ID: <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>

On Mon, 24 Mar 2025 15:08:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - whitespace

Changes requested by lmesnik (Reviewer).

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:

> 43:         for(int i = 0; i < 10; i++) {
> 44:             load = mbean.getProcessCpuLoad();
> 45:             if (load == -1.0) {

Please harden test to allow -1.0 on windows only.

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

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2711575803
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010862043

From kevinw at openjdk.org  Mon Mar 24 21:55:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 21:55:20 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v2]
In-Reply-To: <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
 <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
Message-ID: <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>

On Mon, 24 Mar 2025 20:12:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - whitespace
>
> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:
> 
>> 43:         for(int i = 0; i < 10; i++) {
>> 44:             load = mbean.getProcessCpuLoad();
>> 45:             if (load == -1.0) {
> 
> Please harden test to allow -1.0 on windows only.

Thanks yes I was considering that, then I thought it seemed fair to me to permit all platforms to return -1, and as long as they start returning valid values, the test will pass.
But we could make it stricter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010975156

From kevinw at openjdk.org  Tue Mar 25 11:21:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 11:21:28 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

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

  stricter check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/2cfd63ce..453faf4d

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

  Stats: 25 lines in 3 files changed: 7 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24186/head:pull/24186

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

From kevinw at openjdk.org  Tue Mar 25 11:58:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 11:58:26 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v2]
In-Reply-To: <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
 <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
 <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>
Message-ID: <RS9GK1FXVcYAILIGS_mWSwFiVag38sa2O07SwsBKxh4=.f12cfa8c-fa9f-4707-a4c1-41ac00321ce5@github.com>

On Mon, 24 Mar 2025 21:52:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:
>> 
>>> 43:         for(int i = 0; i < 10; i++) {
>>> 44:             load = mbean.getProcessCpuLoad();
>>> 45:             if (load == -1.0) {
>> 
>> Please harden test to allow -1.0 on windows only.
>
> Thanks yes I was considering that, then I thought it seemed fair to me to permit all platforms to return -1, and as long as they start returning valid values, the test will pass.
> But we could make it stricter.

Updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2011933784

From cjplummer at openjdk.org  Tue Mar 25 16:38:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Mar 2025 16:38:13 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line 60:

> 58:     // Careful with these values.
> 59:     private static final long MIN_TIME_FOR_PASS = 1;
> 60:     private static final long MAX_TIME_FOR_PASS = Long.MAX_VALUE / 1000;

I think this is still 9,223,372 seconds. Seems it should be lower. It might be best to work in the opposite direction. Decide how many seconds and then multiply that by 1,000,000,000.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012500672

From lmesnik at openjdk.org  Tue Mar 25 17:55:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 17:55:13 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <fXlvGq7Yu-z0x44-PDWA73n7vugOmA-mfvM4q5ZoNfo=.0fe93530-5889-4cce-805c-6ea148ed255b@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

Generally, changes looks good for me. Please address @plummercj comments.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2714674461

From lmesnik at openjdk.org  Tue Mar 25 18:02:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 18:02:13 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

The only one generic question: doesn't it makes sense to update JMX to retry several times if Windows 2029 returns -1.0 or undefined to make JDK more reliable?
Are tools like JMC/VisualVM suffer from this issue or they make a lot of request to track data and can live with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752098518

From kevinw at openjdk.org  Tue Mar 25 20:58:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 20:58:07 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
 <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>
Message-ID: <Nq5aAhmrLllZpuRomhnbmHZpud7KeA2FT-Sbtxa7Z6Q=.10472312-895b-46fa-80aa-918a5b9d0002@github.com>

On Tue, 25 Mar 2025 17:57:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The only one generic question: doesn't it makes sense to update JMX to retry several times if Windows 2029 returns -1.0 or undefined to make JDK more reliable? Are tools like JMC/VisualVM suffer from this issue or they make a lot of request to track data and can live with this.

Yes, I was bit worried about adding the overhead of repeating the call, maybe 5 times, with short sleeps, in the MBean CPU monitoring code.  It's been this way "forever", and is documented to return a negative value when info is "not available", so it is still delivering what it promises.  
In our CI it's only Windows Server 2019 10.0 (amd64) where we see a problem.  I don't see actual user reports of it being a problem.  Once the call "works" it seems stable,  so maybe the test is fast to startup and sees the problem.  I think it's better to have the retry on (rare) failure than have the test delay to try and miss the problem, I don't know how reliable that would be without more investigation (which does not seem worthwhile right now).  That may also relate to no reports from JMC/JConsole, but I'm just speculating now. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752526446

From lmesnik at openjdk.org  Tue Mar 25 21:35:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 21:35:13 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <94CgHQiLhyfJHmHpoNNarJhvUK2TQvTVt8LrpNN9Si4=.b40c8b8c-0a40-4775-8fc4-e83184c17bae@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

That's fine then.

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752596081

From kevinw at openjdk.org  Tue Mar 25 21:40:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 21:40:17 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v3]
In-Reply-To: <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
 <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>
Message-ID: <6mvFHY2u0BQtTIKcGhrINuK49i1hpKSxd_x8DbsXyGA=.879b79b1-7b7b-47d7-9b14-b47cfefe3e14@github.com>

On Tue, 25 Mar 2025 16:35:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stricter check
>
> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line 60:
> 
>> 58:     // Careful with these values.
>> 59:     private static final long MIN_TIME_FOR_PASS = 1;
>> 60:     private static final long MAX_TIME_FOR_PASS = Long.MAX_VALUE / 1000;
> 
> I think this is still 9,223,372 seconds. Seems it should be lower. It might be best to work in the opposite direction. Decide how many seconds and then multiply that by 1,000,000,000.

Yes... 
My concern was that 0x7FFFFFFFFFFFFFFF if actually returned, must surely indicate a problem, and the test has been checking if a long is > Long.MAX_VALUE, which can't be useful.  So reducing it even slightly at least give the check some meaning.

I can reduce the value further...
The test obviously avoids guessing what the value should be, to avoid it varying too much one day, and causing a failure.

I've seen the test with -Xcomp, log ns value of 48,580,000,000 but there might be much slower runs out there.

If I use Long.max_value / 10000000 it would have to be about 20 times slower to cause a failure.

Long.max_value / 1000000 =     9,223,372,036,854
Long.max_value / 10000000 =      922,337,203,685
Xcomp example                     48,580,000,000

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012976566

From kevinw at openjdk.org  Tue Mar 25 21:46:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 21:46:26 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v4]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

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

  stricter max time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/453faf4d..c420e213

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=02-03

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

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

From sspitsyn at openjdk.org  Wed Mar 26 00:19:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 00:19:12 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v4]
In-Reply-To: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
Message-ID: <J92CRiu2F5qTnQixbl7tddNRSxX3zQyUldjm-aONUss=.1e102c9c-06e6-4ea7-a055-4c8b4a4e7976@github.com>

On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter max time

The fix is a little bit hacky but as a work around should be okay.
LGTM

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2715462558

From kevinw at openjdk.org  Wed Mar 26 09:06:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Mar 2025 09:06:16 GMT
Subject: jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean
 cpuLoad tests fail intermittently [v4]
In-Reply-To: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
Message-ID: <FNkizekIQW5UV2FDF2Jv_FS9PT7M8bbOhQaEPX2kb5Y=.56c7b03d-3b78-4334-a1dd-8fe799c10c69@github.com>

On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter max time

Thanks for all the reviews and comments.

The timing check in GetSystemCpuLoad.java is a little hacky.  That test has never claimed to try and test that the cpu time is "correct", but now it will at least test the time measured is not crazy.  If I got the definition of "crazy" wrong, will be back here...

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2753660969

From kevinw at openjdk.org  Wed Mar 26 09:06:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Mar 2025 09:06:17 GMT
Subject: jmx-dev Integrated: 8351002:
 com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <ZryRcJH787BV0FDbgYLXkUf37i7RFn37xp9VZwnlrVg=.ea8144d9-0c42-42bf-ae53-a04561cd4569@github.com>

On Mon, 24 Mar 2025 10:13:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

This pull request has now been integrated.

Changeset: eb6e8288
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb6e8288c628577ce557266773ffebdf0bbe853a
Stats:     71 lines in 4 files changed: 51 ins; 6 del; 14 mod

8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently

Reviewed-by: sspitsyn, lmesnik

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

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