On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls 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.
On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls 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 mov
On Thu, 6 Mar 2025 14:13:51 GMT, Kevin Walls 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 dro
On Thu, 6 Mar 2025 13:25:26 GMT, Jaikiran Pai 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, i
On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls 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 mov
On Wed, 5 Mar 2025 19:26:14 GMT, Leonid Mesnik 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
On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls 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 mov
On Tue, 4 Mar 2025 08:14:52 GMT, Kevin Walls 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";
>>> 29
On Tue, 4 Mar 2025 06:42:09 GMT, David Holmes 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 chan
On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls 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 mov
On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls 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
On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls 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 mov
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.
13 matches
Mail list logo
