I assume that if you have a reference to one of these classes from outside the application then it can prevent some classes to be GC'ed, like a static reference you created in some global class? Is this mostly the case, or is it more specialized?
Q On Mon, Sep 14, 2009 at 6:58 PM, Quintin Beukes <[email protected]> wrote: > I have read about this problem many times, and can never really > understand that if the PermGen is GC'ed how a memory leak can occur > that would cause a crash? > > After all, if all references to a Class is cleared it should be GC'ed, right? > > My understanding of how these memory leaks occur in these dynamically > loading containers, like app servers (deployment), servlet containers > (deployment), OSGi (bundles), etc. That means the same class is loaded > many times, and sometimes anonymous/embedded classes in them, and > dynamically generated classes (like proxies in Geronimo). Now, if you > undeploy, won't this clear all references to these classes? > > Can you give me an example scenario of a real life memory leak which > causes a leak and eventually PermGen OOME. > > Thanks, > Q > > On Mon, Sep 14, 2009 at 5:06 PM, Kevan Miller <[email protected]> wrote: >> >> On Sep 14, 2009, at 10:07 AM, Quintin Beukes wrote: >> >>> Doesn't Sun have a GC on the PermGen? Or is it just low priority, >>> meaning this won't happen on production servers. Even in a the common >>> production host you deploy a lot. They might be further apart, but >>> they are many none the less. And these servers are usually solid, >>> meaning they don't fall over. I will easily reach 10 deployments >>> without a server restart. >> >> Yes, PermGen is GC'ed. However, if there is a ClassLoader memory leak, then >> a ClassLoader (and associated classes) can't be GC'ed, even though the >> application has been undeployed. >> >>> >>> Though on my dev machine I have gone to about 20 deployments (around >>> there - I just counted the log entries from server start while >>> pressing page down the whole time and counted 18) before it gave a >>> permgen. This was in a 2 hour period. >>> >>> If this is going to be a problem, is JRocket expensive? >> >> I assume that JRockit stores class meta data in heap space. So, just means >> you have more storage for your class meta data, rather than specialized >> PermGen. >> >> If you recreate your OOME PermGen with -XX:+HeapDumpOnOutOfMemoryError, we >> can help diagnose your problem. One of these days, I'll write a blog on >> this... >> >> --kevan >> >> > > > > -- > Quintin Beukes > -- Quintin Beukes
