All of the scenarios you describe below suggest, then, that so long as a strong reference is held to the class, the class is not eligible for unloading. That means, of course, that once all strong references have been dropped, the class is now eligible for unloading.
Which is exactly how--in theory--it works today. Which means we're really not changing anything. Which means I suspect you're not really talking about just allowing GC to happen, but want to "force" it somehow, which means going above and beyond the conservative collection behavior the JVM has historically espoused. (I am trying to summarize and paraphrase here, to make sure I understand the general thrust of what you're looking for--if I'm putting words in your mouth, by all means, loudly and emphatically tell me. ;-) ) Dropping the Vector out of the ClassLoader base class I think breaks a bunch of other stuff, but I don't remember why. (It's been a while since I tried to track that guy down.) I vaguely recall it being added in 1.2 for a particular reason. IIRC, there's another collection of hard references buried inside the native code, from what I understand, called the Loaded Class Cache (LCC), and those references would likely keep the class alive even if you could yank it out of that Vector. I also believe that Class needs to hard reference the ClassLoader in order to support the getResource() behavior on Class, which means we can't get rid of those strong references, either. I dunno who at Sun owns the ClassLoader facilities in the JVM these days--I got my LCC info from Peter Kessler (sp?) at Sun, IIRC. He/she would be the right one to tell us why that Vector exists, or if what you want is even remotely feasible under the current JVM architecture. Anybody know who that might be? (I'd love to know, just so I can ask some related but off-topic questions, too. ;-) ) 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 Charles Oliver Nutter > Sent: Tuesday, January 15, 2008 12:57 AM > To: [email protected] > Subject: [jvm-l] Re: Ability to force class unloading in JDK 6 Update > 4? > > > Ted Neward wrote: > > Hate to say it, Kresten, but I don't think you'll ever see this--the > > semantics of unloading classes, except by GC, would need to be worked > out > > and codified someplace before this could happen. > > I think the thing Kresten is looking for is an ability to unload > classes > (or make them eligible for GC) when they are known to be unused. Or if > he's not, that's what I want. > > > Assume for the moment that we go with a simpler implementation, > > System.classGC() that takes a Class object and unloads it. (Ignore > the > > complications of ClassLoaders for now.) Suppose... > > (*) ... there is an instance of that Class still reachable in the > system? > > What should happen? > > It's a hard reference; there's nothing new here. An object references > its class. > > > (*) ... this is an abstract class that is inherited by other classes > in the > > system (which may or may not have instances still reachable)? > > A child class has a hard reference to a parent class. No problem. > > > (*) ... you're in the middle of a static method execution call on > that class > > on another Thread? > > Then there's a hard reference to that class from that thread or from > frame executing it. > > > (*) ... another thread is *about* (say, five seconds from now) to > make a > > static method execution call on that class? > > Can't predict the future; but if the caller already has a reference to > the class it wouldn't be able to go away. > > In general, if all reference to a class go away, there should be a way > to make it eligible for immediate GC. > > The larger issues, as I understand them, relate to static initializers. > In order to guarantee the static initializers don't fire again under a > given classloader, there must be guarantees about classes staying > alive. > If they could GC when there are no more references to them, their > static > initializers could fire again. > > However, there's a lot of uses for classes that don't require such > guarantees, such as generating anonymous classes to hold code compiled > at runtime. I don't care if the classes I compile in JRuby's JIT get > unloaded or reloaded, because I'll manage my own references to them. > But > because of the Vector in ClassLoader...they tend to stick around too > long without ClassLoader tricks. > > - Charlie > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.2/1222 - Release Date: > 1/13/2008 12:23 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.5/1228 - Release Date: 1/16/2008 9:01 AM --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
