Hi all, Just finished listening to 393 while on my way back home from Zurich. I've been watching the removal of PermGen and I have to say that I'm not all the excited about it leaving us. Dick mentioned that reloading applications into TomCat could fill up perm space. Indeed it does but the old app you've replaced should be GC'ed.. but it can't be because of dreaded classloader leaks. And that is only one scenario where a developer, doing nothing wrong, ends up leaking classes into perm space. I should point out that IBM's JVMs and JRockit, neither of which have permgen also suffer from this classloader leak problem. The problem is; those classes leak into general heap space and this degrades GC throughput while it fills up heap until eventually you degrade into Full GCs and the OOME. WIth Perm Gen you run out of memory (sooner) but in a way that doesn't degrade performance while it's happening. Removing Perm Gen is fixing the symptom, not the problem.ac
Not exactly what you're looking for but there is a Thread constructor that allows you to set Java stack size. The problem with native stack is that it's sandwiched between text and C heap. You'd have to move C heap to dynamically change the size of a stack frame and although we can do that for stuff in Java heap... I don't know how you'd do it generically in C heap. But again, this problem would be mute if proper support for recursion was put into the JVM. -- Kirk -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
