[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Integrated: 8237542: JMapHeapConfigTest.java doesn't work with negative jlong values
From:       Chris Plummer <cjplummer () openjdk ! org>
Date:       2023-08-25 23:19:17
Message-ID: dtOSem146ihzAfhV_HMA4oyKM7X-1tQ7DuskU_fSZSw=.a9606a0b-cf14-47e7-9c68-47a9ca4e63a9 () github ! com
[Download RAW message or body]

On Mon, 21 Aug 2023 19:25:25 GMT, Chris Plummer <cjplummer@openjdk.org> wrote:

> The test tries to match up various GC -XX:+PrintFlagsFinal values with the output \
> of jhsdb -jmap --pid <pid> --heap. With ZGC, MaxNewSize set to (size_t)-1, but \
> PrintFlagsFinal prints it as an unsigned long: 
> size_t MaxNewSize = 18446744073709551615 {product} {default} 
> 
> jmap normally prints out both the raw size and the MB size. For example:
> 
> MaxHeapSize              = 805306368 (768.0MB)
> 
> But as part of the fix for \
> [JDK-6718125](https://bugs.openjdk.org/browse/JDK-6718125), it stopped printing the \
> raw value for negative values an only printed the MB value. So for MaxNewSize we \
> had: 
> MaxNewSize = 17592186044415 MB
> 
> Instead of:
> 
> MaxNewSize = 18446744073709551615 (17592186044415 MB)
> 
> So the test fails to find 18446744073709551615 in the output. I fixed jmap to \
> include the raw value as an unsigned long, even if negative as a signed long (to be \
> consistent with PrintFlagsFinal output), so now the test passes even when \
> MaxNewSize is included in the list.

This pull request has now been integrated.

Changeset: 8a5db6ba
Author:    Chris Plummer <cjplummer@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a5db6bab343cdea667ea4b0e985574f75332d3e
                
Stats:     19 lines in 2 files changed: 6 ins; 7 del; 6 mod

8237542: JMapHeapConfigTest.java doesn't work with negative jlong values

Reviewed-by: sspitsyn, shade

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

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


[prev in list] [next in list] [prev in thread] [next in thread]