RFR[8u]: 8164293: HotSpot leaking memory in long-running requests

[Jamsheed C m]

Thank you for the review, Vladimir.

Best Regards,

Jamsheed


On 1/10/2017 10:39 PM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 1/6/17 4:11 AM, Jamsheed C m wrote:
>> Thank you for the review, Tobias.
>>
>> could i get a second review please.  also, request for approval from
>> 8u-dev.
>>
>> Best Regards,
>>
>> Jamsheed
>>
>>
>> On 11/23/2016 3:43 PM, Tobias Hartmann wrote:
>>> Hi Jamsheed,
>>>
>>> On 22.11.2016 17:41, Jamsheed C m wrote:
>>>> Hi,
>>>>
>>>> On 11/22/2016 6:09 PM, Jamsheed C m wrote:
>>>>> Hi Tobias,
>>>>>
>>>>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote:
>>>>>> Hi Jamsheed,
>>>>>>
>>>>>> On 22.11.2016 08:37, Jamsheed C m wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Request for review.
>>>>>>>
>>>>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/
>>>>>> I think the resource marks in the sweeper could be "moved up" in
>>>>>> the scope but looking at the JDK 9 code, we have them at the places
>>>>>> you suggested so I think it's fine for consistency reasons. The JDK
>>>>>> 9 code is not affected because it was fixed with JDK-8046809, right?
>>>>> Yes, Done.
>>>>>>    Please add this as a comment to the bug.
>>>>>>
>>>>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing
>>>>>> in JDK 9 code.
>>>>> This one was causing  the  leak in sweeper task(product build
>>>>> without logging option).  RM added in
>>>>> NMethodSweeper::sweep_code_cache should be enough as it is sole user
>>>>> of the function. I added RM in clear_ic_stubs too to make sure that
>>>>> there is no misses in future. It is good to have change in JDK9, as
>>>>> said in (https://bugs.openjdk.java.net/browse/JDK-8059675)
>>>>>
>>>>>>> Desc: There were a few  memory leaks in thread arena due to
>>>>>>> sweeper task.
>>>>>>>
>>>>>>> Fix: Applied ResourceMark wherever applicable.
>>>>>>>
>>>>>>> The slow growth of mtClass malloc(the one reported in bug) is not
>>>>>>> memory leak. It is application behavior in low codecache size
>>>>>>> setting( frequent sweeps), more InstanceKlass requires OopMapCache
>>>>>>> initialized here.
>>>>>> Could you please elaborate on this? Why do we create more
>>>>>> InstanceKlasses? And why is this behavior not stabilizing?
>>>>> It doesn't create more InstanceKlasses. No of InstanceKlasses is
>>>>> 5649 is kind of stable.  OopMapCache for an InstanceKlass get
>>>>> initialized on first request (Interpreter frame walk during gc).
>>>>> Stabilizing thing is yet to be checked as i did all my analysis in
>>>>> debug mode(with gdb attached).  It is confirmed that the rate of
>>>>> memory growth in steadily decreasing, and all OopMapCache allocation
>>>>> happen for unique InstanceKlass.
>>>> i meant "each OopMapCache allocation happen for unique
>>>> InstanceKlass", sorry for the typo.
>>> Okay, as we discussed offline, please file a new bug to keep track of
>>> the OopMapCache issue.
>>>
>>> I'm fine with the current sweeper fix (not an 8u reviewer).
>>>
>>> Thanks,
>>> Tobias
>>>
>>>> Best Regards,
>>>> Jamsheed
>>>>> i have a product instance with fixes running now for a day. i can
>>>>> wait a few more days to  confirm that i don't miss anything.
>>>>>
>>>>> Best Regards,
>>>>> Jamsheed
>>>>>
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Jamsheed
>>>>>>>
>>