RFR[8u]: 8164293: HotSpot leaking memory in long-running requests
Jamsheed C m
jamsheed.c.m at oracle.com
Tue Nov 22 16:41:35 UTC 2016
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
>>> Desc: There were a few memory leaks in thread arena due to sweeper
>>> 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
i meant "each OopMapCache allocation happen for unique InstanceKlass",
sorry for the typo.
> 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,
>>> Best Regards,
More information about the hotspot-compiler-dev