This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
Ramesh, It should. Classes are objects. So are static members of a class. GC occurs sometime after there are no references to that object. You can try to force GC, but the exact timing is more of a mystery. I don't know a whole lot about GC, so I'm sure there's someone else out there with something better to say. Hint, hint. Cheers, Scott
Absolutely! Classes are "unloaded". That is the term they use, not "Garbage Collected". You might want to checkout the JLS Section 12.7 Unloading of Classes and Interfaces. The implementation of this feature is considered as an optimization technique and is not guaranteed to be present in all Java VMs. However it is not uncommon to see custom class unloaders for applications running in low resource situations - embeded devices, mobile phones etc. Hope that helps! ------------------ Ajith Kallambella M. Sun Certified Programmer for the Java�2 Platform. IBM Certified Developer - XML and Related Technologies, V1.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Scott, I hope you weren't talking about me being the one "with something better to say", because you pretty well covered it! About the only thing I can think of to add is that you may be able to use the noclassgc option to prevent garbage collection of classes. However, noclassgc is a "non-standard" option, which means that a JVM may or may not provide support for it. You should be able to find out whether or not it is supported by issuing a command like this one: java -X
Assuming that it is supported, you'd specify noclassgc using a command like the following: java -Xnoclassgc MyApp
This is assuming that you're using a Java 2 JVM, because if I recall correctly, you'd leave out the "X" if using with an older JVM. For example: java -noclassgc MyApp
Ajith, You mean as part of a custom JVM in certain embedded/mobile devices, correct? (In other words, the "class unloader" is code implemented in the JVM) ------------------
Yes you're right. The tricky part here is to decide when to unload the class. Since class loading and bytecode verification has its own overheads, if you unload a class too quickly you will risk introducing a cost into subsequent loadings. I guess that's what makes it hard to write a generalized unloading algorithm - it has to be driven by specific requirements.
------------------ Ajith Kallambella M. Sun Certified Programmer for the Java�2 Platform. IBM Certified Developer - XML and Related Technologies, V1.
Well this is quite an old post. Garbage collection can occur for classes, but only when the classloader that loaded the class may also be collected.
A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector. Class unloading is an optimization that helps reduce memory use. Obviously, the semantics of a program should not depend on whether and how a sstem chooses to implement an optimization such as class unloading. To do otherwise would compromise the portability of programs. Consequently, whether a class or interface has benn unloaded or not should be transparent to a program. However, if a class or interface C was unloaded while its defining loader was potentially reachable, then C might be reloaded. One could neve ensure that this would not happen. Even if the class was not refenced by any other currently loaded class, it might be refernced by some class or interface, D, that had not yet been loaded. When D is loaded by C's defining loader, its execution might cause reloading of C. Reloading might not be transparent if, for example, the class has:
Static variables (whose state would be lost)
Static initializers (which may have side effects)
Native methods (which may retain static state)
Since it is unsafe to unload a class whose classloader may still be referenced, it is not done. The bootstrap loader is never unloaded.
0
About the only thing I can think of to add is that you may be able to use the noclassgc option to prevent garbage collection of classes. However, noclassgc is a "non-standard" option, which means that a JVM may or may not provide support for it. You should be able to find out whether or not it is supported by issuing a command like this one: