RFR 8204128: NMT might report incorrect numbers for Compiler area

[Zhengyu Gu]

On 11/15/19 3:09 PM, Thomas Stüfe wrote:
> All good now.

Thank you, and pushed.

-Zhengyu

> 
> .. Thomas
> 
> On Fri, Nov 15, 2019, 19:37 Zhengyu Gu <zgu at redhat.com 
> <mailto:zgu at redhat.com>> wrote:
> 
>     Thanks, Thomas
> 
>     On 11/15/19 12:59 PM, Thomas Stüfe wrote:
>      > Hi Zhengyu,
>      >
>      > wouldn't ssize_t not be a better choice?
> 
>     You are right!
> 
>     Updated:
>     http://cr.openjdk.java.net/~zgu/JDK-8204128/webrev.01/index.html
> 
>     Reran the tests.
> 
>     -Zhengyu
> 
>      >
>      > Other than that, looks good.
>      >
>      > ..Thomas
>      >
>      > On Fri, Nov 15, 2019 at 4:08 PM Zhengyu Gu <zgu at redhat.com
>     <mailto:zgu at redhat.com>
>      > <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>> wrote:
>      >
>      >     I could not reproduce the problem stated in CR.
>      >
>      >     The theory is that, when releasing a 2GB+ arena,
>      >     Arena::set_size_in_bytes() passes a negative long integer to
>     NMT, when
>      >     it goes through long -> int -> long conversion, at the end, it
>      >     becomes a
>      >     positive number.
>      >
>      >     This problem is illustrated in new test. Without the fix, after
>      >     releasing a 2GB+ arena, NMT shows the arena size doubled,
>     instead of
>      >     going down.
>      >
>      >     I am not completely sure this fixes the problem reported, but
>     it is
>      >     worth to cleanup inconsistent types in NMT API.
>      >
>      >
>      >     Bug:
>     http://cr.openjdk.java.net/~zgu/JDK-8204128/webrev.00/index.html
>      >     Webrev:
>     http://cr.openjdk.java.net/~zgu/JDK-8204128/webrev.00/index.html
>      >
>      >     Test:
>      >         hotspot_nmt + new test (fastdebug and release)
>      >         on Linux x86_64
>      >
>      >     Thanks,
>      >
>      >     -Zhengyu
>      >
>