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

Tobias Hartmann tobias.hartmann at oracle.com
Tue Nov 22 08:27:47 UTC 2016

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

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


> Best Regards,
> Jamsheed

More information about the hotspot-compiler-dev mailing list