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

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area
From:       Zhengyu Gu <zgu () redhat ! com>
Date:       2019-11-26 14:29:40
Message-ID: 3a2c2045-717e-6282-dcdd-40342f091177 () redhat ! com
[Download RAW message or body]


>>
>> But I leave it up tp you if you change this. If you just reorder the 
>> calls, I do not need another Webrev,
> 
> I will re-order the calls, as you suggested.

Passed submit tests and pushed.

Thanks, Thomas and Yumin

-Zhengyu

> 
> Thanks,
> 
> -Zhengyu
> 
>>
>> ...
>>
>> Another unrelated question, what is the reason for the unusual 
>> creation of MallocMemorySummarySnapshot with placement new? Why not 
>> just put it as a member into  MallocMemorySummary? I must be missing 
>> something.
>>
>>
>>        -Zhengyu
>>
>>
>>
>>          >
>>          >      66       wb.NMTFreeArena(arena1);
>>          >
>>          > On Mon, Nov 25, 2019 at 2:30 PM Zhengyu Gu <zgu@redhat.com
>>        <mailto:zgu@redhat.com>
>>          > <mailto:zgu@redhat.com <mailto:zgu@redhat.com>>> wrote:
>>          >
>>          >        Ping ... May I get a second review?
>>          >
>>          >        Thanks,
>>          >
>>          >        -Zhengyu
>>          >
>>          >        On 11/21/19 12:12 PM, yumin qi wrote:
>>          >         > Hi, Zhengyu
>>          >         >
>>          >         >      The fix looks good to me.
>>          >         >
>>          >         > Thanks
>>          >         > Yumin
>>          >         >
>>          >         >
>>          >         >
>>          >         > On Wed, Nov 20, 2019 at 5:49 AM Zhengyu Gu <zgu@redhat.com
>>        <mailto:zgu@redhat.com>
>>          >        <mailto:zgu@redhat.com <mailto:zgu@redhat.com>>
>>          >         > <mailto:zgu@redhat.com <mailto:zgu@redhat.com>
>>        <mailto:zgu@redhat.com <mailto:zgu@redhat.com>>>> wrote:
>>          >         >
>>          >         >        JDK-8204128 did not fix the original bug. But new
>>        assertion
>>          >        helped to
>>          >         >        catch the problem, as it consistently failed in Oracle
>>          >        internal tests.
>>          >         >
>>          >         >        The root cause is that, when NMT biases a resource 
>> area to
>>          >        compiler, it
>>          >         >        did not adjust tracking data to reflect that. When the
>>        biased
>>          >        resource
>>          >         >        area is released, there is a possibility that its 
>> size is
>>          >        greater than
>>          >         >        total size recorded, and underflow a size_t counter.
>>          >         >
>>          >         >        JDK-8204128 patch also missed a long to ssize_t 
>> parameter
>>          >        type change,
>>          >         >        that resulted new test failure on Windows, because 
>> long is
>>          >        4-bytes on
>>          >         >        Windows.
>>          >         >
>>          >         >        Many thanks to Leonid Mesnik, who helped to run this 
>> patch
>>          >        through
>>          >         >        Oracle's internal stress tests.
>>          >         >
>>          >         >        Bug: https://bugs.openjdk.java.net/browse/JDK-8234270
>>          >         >        Webrev:
>>          > http://cr.openjdk.java.net/~zgu/JDK-8234270/webrev.00/index.html
>>          >         >
>>          >         >
>>          >         >        Test:
>>          >         >              hotspot_nmt
>>          >         >              Submit test
>>          >         >              Oracle internal stress tests.
>>          >         >
>>          >         >
>>          >         >        Thanks,
>>          >         >
>>          >         >        -Zhengyu
>>          >         >
>>          >
>>

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