wood burning stoves 2.0*
The moose likes Java in General and the fly likes garbage collection of classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "garbage collection of classes" Watch "garbage collection of classes" New topic
Author

garbage collection of classes

Ramesh Donnipadu
Ranch Hand

Joined: Sep 16, 2000
Posts: 100
Hi,
Does GC also work on classes? Specifically, does GC free memory allocated to static members of class?
Thanks,
Ramesh
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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
Ranch Hand

Joined: Sep 28, 2000
Posts: 88
Hi
You can find the further information about the GC from here
http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/
Surya
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
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).
Brett Spell
Ranch Hand

Joined: Feb 24, 2001
Posts: 96
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
Ranch Hand

Joined: Jan 24, 2001
Posts: 219
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


<UL TYPE=SQUARE><I><LI>Ryan Burgdorfer<BR><LI>Java Acolyte</I></UL>
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
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
Ranch Hand

Joined: Jun 27, 2002
Posts: 401
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.


    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: garbage collection of classes