garbage collection of classes

[Ramesh Donnipadu]

Hi,
Does GC also work on classes? Specifically, does GC free memory allocated to static members of class?
Thanks,
Ramesh

[Anonymous]

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

[Surya Bahadur]

Hi
You can find the further information about the GC from here
http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/
Surya

[Ajith Kallambella]

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.

[Brett Spell]

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

------------------
Brett Spell
Author, Professional Java Programming

[ryan burgdorfer]

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)
------------------

• Ryan Burgdorfer
  
• Java Acolyte in
  
• Columbus, OH USA
  

[Ajith Kallambella]

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.

[Garrett Smith]

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.