I think you misunderstand me here Ted. My intention would be to have it such that classes loaded by a specific kind of class loader is eligible for GC when there are no references to the class (usually that there are no instances of said class). Such semantics is not possible today because class loaders have a strong link to classes loaded by it.
So what I suggest is to have a new special kind of class loader (TransientClassLoader maybe) which doesn't have the strong link to classes loaded by it. If this was a new class, then no existing code would be broken by it; and so the new semantics for when a class is eligible for class unloading would only apply to classes loaded by transient class loader (ad subclasses thereof). Kresten On Jan 17, 10:26 am, "Ted Neward" <[EMAIL PROTECTED]> wrote: > 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, Writinghttp://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 -~----------~----~----~----~------~----~------~--~---
