RFR 8204128: NMT might report incorrect numbers for Compiler area

[Zhengyu Gu]

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>> 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
>