> From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Subject: Re: PermGen space [ot] > > But as long as the factory itself isn't linked by an attribute which > is inside the impl, the factory class can be released.
Not if there's a direct reference to the factory class somewhere, rather than a reference by reflection. Any class entries in the constant pool of another live class are considered active by GC, and therefore cannot be discarded. Accessing the factory by reflection avoids this, since the reference is symbolic, not direct. Likewise, referencing the original singleton class in your example via reflection would also allow it to be collected once the caller nulled out its own reference to the returned singleton. > As soon as the factory class is released nothing references > the singleton impl object and it can be released. Agreed - the trick is avoiding the direct reference to the factory class. > Now without the factory, we have a situation where the > classloader can't be released since its referenced by the class > object, which is referenced by the impl object, which is again > referenced by the class object (as the static variable). The above is not a problem - the only thing keeping that set from being GC'd is some direct reference from outside the set. Again, using reflection instead of the direct reference would allow the set to be collected. > With suns jdk 1.5 i actually experienced oome on redeploy with code > without any issues mentioned by your article. After we removed > singleton dependency it went away. And what else changed? Note that the Sun JVM has a history of subtle bugs which prevent proper GC operation in odd cases. One such example is this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5033614 In this instance the server compiler created an exception object that hung around essentially indefinitely, and it contained a stack trace that happened to hold a reference to an otherwise dead object. That one reference prevented GC of the object, class, and classloader. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
