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

[Vladimir Kozlov]

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