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

[Jamsheed C m]

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