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

[David Buck]

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