Sounds like that's exactly what it does - includes a permgen sweep on explicit System.gc() invocation.
I have very mixed feelings about this. I mean, in a properly implemented (ideal) JVM, why would you ever need this (or any other explicit GC, for that matter)? OTOH, leaving ideal worlds aside, it can be a blessing if you'd ever have a programmatic need to nudge (a real world, non-ideal) VM into freeing up unused code. But still, the implementation bothers me. Applications shouldn't have explicit System.gc() invocations, and even if I wanted to suggest the JVM it'd be good time to do a permgen sweep, I think it's a bad idea to overload System.gc() as the API for that purpose (and then operationally rely on JVM being launched with this new command line flag). Adding a method to either ClassLoadingMXBean or GarbageCollectorMXBean in java.lang.management would've been a much cleaner approach. Attila. On 2008.01.14., at 8:49, Charles Oliver Nutter wrote: > > I stumbled across a blog post mentioning a new feature in an > "experimental VM"...but perhaps it's now in JDK 6 Update 4? > > -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses > > Anyone know about it? > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6541037 > > I would expect that it doesn't change the fact that ClassLoader > holds a > hard reference to all classes it loads, but perhaps it helps force > dereferenced classes in dereferenced classloaders to get collected > more > quickly? > > - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
