RFR 8204128: NMT might report incorrect numbers for Compiler area

[Thomas Stüfe]

All good now.

.. Thomas

On Fri, Nov 15, 2019, 19:37 Zhengyu Gu <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>> 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
> >
>
>