On 2008.01.15., at 6:30, Ted Neward wrote:
> > +1. > > But adding this to the GCMXBean would mean changing that interface, > and that > gets into all sorts of versioning problems. Well, the implementation itself is usually provided by the JVM, so it shouldn't be a too big a problem. Still, I see your point. > Perhaps a better way would be to > create a new GCMXBean interface (let's call it > GarbageCollectorMXBean2 just > for cruelty's sake) You just reminded me of good ol' COM programming days: IClassFactory, IClassFactory2. I think some DirectX interfaces actually reached into threes... Attila. > and offer it through the JMX server as well. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: [email protected] [mailto:jvm- >> [EMAIL PROTECTED] On Behalf Of Attila Szegedi >> Sent: Monday, January 14, 2008 12:42 AM >> To: [email protected] >> Subject: [jvm-l] Re: Ability to force class unloading in JDK 6 Update >> 4? >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
