Code cache size

John Mazzitelli mazz at redhat.com
Fri Aug 10 00:54:46 UTC 2012


this is a known issue - see BZ https://bugzilla.redhat.com/show_bug.cgi?id=727245 titled "RHQ Agent leaks java classes when issued command "plugins update"" This was noticed when doing work on another issue - see this comment: https://bugzilla.redhat.com/show_bug.cgi?id=615377#c10

----- Original Message -----
> 
> 
> tl;dr: don't panic
> 
> 
> 
> Just wanted to share this interesting post about JVM memory
> 
> 
> http://blogs.amd.com/developer/2010/04/12/better-uptime-for-long-running-java-applications/
> 
> 
> In jconsole in the memory tab, there is a drop down about the
> individual regions, and there is
> one entry for the code cache as well:
> 
> 
> 
> 
> 
> So the marked spots on the graph are when I invoked "plugins update"
> on the agent command line. In all cases, the plugins
> on the agent were up-to date. So this can't come from loading a new
> plugin that is much "fatter" than the older one.
> 
> 
> Looking at those figures, we indeed seem to have a tiny code cache
> leak in the agent.
> Most of the times no one will see it, as the max code cache size is
> (here) 48M, while the agent starts with 8MB and a plugins update
> (even if all plugins are already up to date) adds ~1.5MB. So users
> that run the agent in production will never do 20 plugin upadate
> cycles as production agents are not constantly updated.
> And developers usually don't have the agent running to long enough to
> ever run into it
> 
> 
> Interestingly the invocation of "Perform GC" had no influence here.
> What happened though is that a longer time after
> I took above graph, a gc collected some of the added memory in the
> code cache (but not back to the original 8MB)
> but the committed value did not go down. Overall it is mostly stable
> though (doing some plugin redeploys with
> changed code base right now):
> 


More information about the rhq-devel mailing list