hi mark, thank you for showing my mistake. my apology to chuck also. i will read the article.
--- daniel baktiar http://savinggaia.tritiumapps.com - saving the planet is everyone's business! On 23 November 2010 18:50, Mark Thomas <ma...@apache.org> wrote: > 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 > >
