On 23/11/2010 06:55, Daniel Baktiar wrote: > hi charles, > > please allow me to disagree to that "hanging onto reference" as the main > issue.
Daniel, You are completely wrong. I suggest you read this: http://wiki.apache.org/tomcat/MemoryLeakProtection and try out some of the sample code with a profiler. > permgen space is garbage collector's specific issue, not general "hanging > onto reference issue". it is caused by redeployment, which is the metadata > for classes, marked to be permanent generation by the hotspot garbage > collector. when you deploy new classes, the class loader will introduce > memory usages that will also marked as permanent generation. That might have been true with the JVMs of 10 years ago. It certainly isn't true today and hasn't been for quite some time. Unused classes can be GC'd from permgen. If you don't believe me, get yourself a profiler and test it for yourself. > permgen is oracle hotspot specific implementation issue. you won't get it > when you run on oracle jrockit (which performs just in time compilation), > for example. Yes you will see the exact same problem in JRockit. However, it will take a lot longer since JRockit stores class information in the Java heap. That means you still have a memory leak but it takes a lot longer for it to trigger an OOME since you have to fill the entire heap first rather than 'just' filling permgen. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
