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

[Jamsheed C m]

Thank you,  David.

Best Regards,

Jamsheed


On 1/11/2017 1:50 PM, David Buck wrote:
> approved for push to 8u-dev
>
> Cheers,
> -Buck
>
>> On Jan 11, 2017, at 11:52, Jamsheed C m <jamsheed.c.m at oracle.com> wrote:
>>
>> 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
>>>>>>>>>