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

[Tobias Hartmann]

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